[Gambas-user] My confusion Re: New Syntax, SUPER && !comprehension(mine) Re.: SUPER example at gambasdoc

[Fabien Bodard]

Le 12 mai 2014 12:12, "Stephen" <sbungay at ...3301...> a écrit :
>
> Hi Tobias, thanks for the reply, things got busy and I'm just getting
> back to the keyboard.
>
> It was how things were being done in the (broken) GAMBASDOC example
> confused me.
> In one area the programmer is using the Add method of a string object
> array, but this line
>
> $cPos[Key] = $aKey.Count
>
> caused me to pause.
>
> My thought at the time of reading it went something like this:
>
> "What being done here? There's been no use of the Add method! How can
> you reference
> something that doesn't yet exist and why is no error being thrown for
> doing so"?

A collection automatically add an non existant entry ... Or just assign the
new value... If the value is null then the entry is deleted.

>
> Now I think that the Add method of the collection is being implicitly
> called using older
> non OOP array assignment syntax.
>
> IMHO enforcing the explicit use of the object's Add method
>
> $cPos.Add($aKey.Count, Key)
>
> might take more keystrokes, but it definitely better communicates what
> is being manipulated (an object vs an array) and what is being done
> (Adding).
>
>
> On 05/08/2014 09:28 AM, Tobias Boege wrote:
> > On Thu, 08 May 2014, Stephen wrote:
> >>     Looking at the thread "New syntax for using variables arguments in
a
> >> function call" I realized that I needed to really brush up on my
> >> somewhat marginal understanding of the evolving (a good thing) GAMBAS
> >> and OOP. Not fully understanding "SUPER" (I've never used it but can
see
> >> a use for it) I trotted off to Google and the GAMBAS documentation,
> >> where much reading was done, and (as usual) more questions raised.
> > If you write a class and inherit from another class, you can override
> > methods and properties in your inheriting class. However, sometimes the
> > inherited class does a pretty good job already and you don't want to
> > reinvent the wheel for doing something. That's when Super comes into
play
> > because Super knows where the method and property implementations of the
> > inherited class (the super class) are. So you can still call methods of
> > the super class in your subclass that you have actually just overridden.
> >
> > In the example below, you want to skim data in ListBox' Add() method but
> > you don't want to implement the actual addition of a new element so you
> > resort to the original ListBox' Add() implementation - which is
available
> > as Super.Add() and knows how to do the thing.
> >
> >>     Studying the "SUPER" example at
http://gambasdoc.org/hemp/lang/super,
> >> I wondered at the purpose of a collection that seems not to be used but
> >> once and some syntax in it's use in the example, which didn't make any
> >> sense to my old brain. Below is a snippet from the example (where $cPos
> >> is a collection, $aKey an Array of String Objects (I think) and Key a
> >> string object;
> >>
> >> $cPos.Clear
> >> $cPos[Key] = $aKey.Count
> >> $aKey.Add(Key)
> >>
> >>     OK, the first line clears the collection, got it, and the last line
> >> adds the contents of "String" to $aKey, got that.... but what does the
> >> second line do? It looks like it is adding the count of elements in
> >> $aKey to the collection $cPos... but in OOP I would use a method call
> >> i.e. $cPos.Add(Key,Key). Oh, and in trying to implement the example
> >> GAMBAS (3.5.3) complained that "ListBox.Add is incorrectly overridden".
> >>
> > $cPos[Key] = $aKey.Count followed by $aKey.Add(Key) will store the
*index*
> > of Key in the $aKey array in the $cPos collection, indexed by the
*value* of
> > the key. (Think about it.)
> >
> > That means if the user gives you a Key, you can look up the index of
that
> > key in the $aKey array using $cPos[Key], i.e. the statement
> >
> >    $aKey[$cPos[Key]]
> >
> > will always return Key (or raise an error, but see below for that). This
> > also explains why the Collection is named $cPos.
> >
> > Not sure what that implies or what we can do with it and how
$cPos.Clear()
> > fits into the picture because it already deletes that additional
information
> > we collected...
> >
> > Either I don't get it or the example is just broken (I'd prefer the
second
> > option, of course :-)).
> >
> > Regards,
> > Tobi
> >
>
>
> --
> Kindest Regards
> Stephen A. Bungay, Prop.
> Smarts On Site
>
>
>
------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user