[Gambas-user] components automatically loading based on usage

[Fabien Bodard]

Le 23 juil. 2013 23:55, "Kevin Fishburne" <kevinfishburne at ...1887...>
a écrit :
>
> On 07/23/2013 04:59 AM, Tobias Boege wrote:
> > On Mon, 22 Jul 2013, Kevin Fishburne wrote:
> >> I just noticed that referencing a boolean variable "Match" now
> >> automatically loads the pcre component and tries to use it as a
function
> >> (then obviously fails). This seems a dangerous precedent, as most
GAMBAS
> >> users probably don't use most components and therefore shouldn't be
> >> constrained by their reserved keywords. Having any component
> >> automatically enable itself for any reason is also troubling, as it
> >> exposes the application to any vulnerabilities the component may
possess
> >> without the knowledge of the developer.
> >>
> >> For the time being I'm just renaming my variable, but I was surprised
to
> >> see this. Thoughts anyone?
> >>
> > Hi Kevin,
> >
> > as you may have read in the commit logs, the Match operator was added by
> > Benoit after I added a static Regexp.Check() shorthand function (which
was
> > subsequently renamed to Regexp.Match()).
> >
> > I personally am very lucky with Match being an operator because it is
more
> > powerful than Like and just looks more natural than a function call -
and
> > extended regular expressions should be part of every language. The thing
> > with "constrained by their reserved keywords" is that Match _is_ now
part of
> > the language - which is IMO a good thing in itself - and you normally
don't
> > plug in keywords into a language. It's not that Gambas will be flooded
by
> > new keywords and the variable namespace will be polluted... A keyword is
> > only added once in a while.
> >
> > I was sceptical, too, when I read that it loads the gb.pcre component
in the
> > background but: you wouldn't use Match if you didn't want to use
gb.pcre,
> > right? In this case, you would accept the risk that gb.pcre was buggy
(and,
> > come on, the component consists of ~400 LOC).
> >
> > That the new keyword could collide with a variable name was something I
> > didn't think about as I stick to the naming conventions[0] ;-) Also if
> > "Match" was a boolean variable, the literate way to name it would have
been
> > HasMatched or something as "match" is an action and "has matched" is a
> > boolean state. Just joking :-)
> >
> > If you still want to use the name Match (e.g. for public symbols,
> > properties, etc.), use braces[1].
> >
> > Regards,
> > Tobi
>
> LOL. Okay, I'll bite. I guess it was the surprise of seeing my variable
> no longer working combined with the bit about a component being
> automatically loaded that made fire shoot out of my eyes. I haven't used
> regular expressions so wasn't familiar with Match being a common
> function name.
>
> To Benoît, the code I had was essentially:
>
> Dim Match As Boolean
> Match = False
>

well it will be better with

Dim bMatch As Boolean
bMatch = False

:-)

> --
> Kevin Fishburne
> Eight Virtues
> www: http://sales.eightvirtues.com
> e-mail: sales at ...1887...
> phone: (770) 853-6271
>
>
>
------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
>
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user