I have this line in my app, and it used to work, but with the new commit it does not:
$hFBrowser = New FBrowser(Settings["/Browser/Width", $Width], Settings["/Browser/Height", $Height], Settings["/Browser/X", $X], Settings["/Browser/Y", $Y])
I'm missing something? Or there is new syntax?
----- Original Message ----
From: Benoît Minisini <gambas@...>
To: mailing list for gambas developers <gambas-devel@...>
Sent: Mon, November 30, 2009 8:08:33 AM
Subject: Re: [Gambas-devel] Arguments of inherited constructors
> Benoît Minisini wrote:
> > There is a change in the Gambas object model in the last revision,
> > about arguments passed to inherited constructors.
> > Let's suppose that you have the following inheritance tree:
> > A --> B --> C
> > When instanciating C,
> Your English is excellent but the correct spelling of 'instanciating" is
> actually "instantiating" :)
My English is not very good: I have a good dictionnary. You never hear me
trying to speak english.
> I made a mental note to fiks that in the documentation.
> (If your English is as good as know it is, you'll get the joke about fiks.)
> > the constructor of A (its _new method) is
> > automatically called, then the constructor of B, and finally the
> > constructor of C.
> > If constructors have arguments, they must be passed to the NEW
> > instruction.
> > Before the last change, the arguments had to be sent in reverse order:
> > New C(Arguments for C._new, Arguments for B._new, Arguments for
> > A._new)
> > Now, they have to be sent in normal order:
> > New C(Arguments for A._new, Arguments for B._new, Arguments for
> > C._new)
> > They are three consequences:
> > 1) You can now have optional arguments in the C constructor.
> > 2) Optional arguments in inherited constructors become mandatory.
> > Note that only the initial constructor could have optional argument
> > before, which I found finally illogical.
> > 3) You must check your code! For example, if you created a form whose
> > constructor has a string arguments, you had to do that before:
> The difference between that and this is another thing I have made a note of
> to ficks in the doco :)
> > MyForm = New MyForm(StringArgument)
> > And now you must do:
> > MyForm = New MyForm(Null, StringArgument)
> > 'Null' is actually the argument of the Window constructor, which is
> > the parent of the Window.
> > Moreover, with that change, I may be able to fix the constructor
> > signature that didn't take inheritance into account until now.
> Ok, serious questions....
> Is there anything at all that the programmer could pass in place of Null?
> If there is, what is it about that formerly Null parameter that
> distinguishes it from StringArgument? In other words, is there anything
> that will enable your code make a decision that "StringArgument" on its
> own really means "Null, StringArgument"? If there is, why force the
> programmer to pass a null if that null is unnecessary?
> That is, does it make sense for a programmer to be forced to pass Null if
> there are codeable rules that can decide what "StringArgument" actually
> means in the absence of the Null in "Null, StringArgument"?
> If that series of questions doesn't make any sense then I promise to crack
> open fewer beers tomorrow.
> As an example, assume A --> B --> C
> If A can't deal with the parameters, then A passes them onto B. If B can't
> deal with the parameters, then B passes them onto C.
> If C can't deal with the parameters, then C says to B, "Yer wot?" And B
> says says to A, "Yer wot?"
> A asks the programmer, "Yer wot?"
> Of course, all of that makes absolutely no sense to me after an hour or
> more of trying to get it to make sense, and having polished off a dozen or
> more Aussie beers inbetween, I'm in no sit ftate to get it to make sense.
> What I'm asking here is probably two-fold:
> 1) Can you make it easier for the programmer by making code-based decisions
> without the need to pass nulls?
> 2) If so, why not make code-based decisions about what the parameters mean?
> That is, essentailly, what the .NET Overrides statement does; It says, "I
> can't deal with these parameters, perhaps you can?"
Optional arguments must be the last ones in Gambas.
A constructor cannot tell the inherited constructor "finally I won't use this
argument, take it". Moreover, it breaks the encapsulation.
The interpreter cannot know if an optional argument will be used or not by a
method. So, when calling inherited constructors one by one, it must assume
that all arguments are mandatory, except for the last constructor. How could
it know that, for example, the second argument is an optional argument of the
first constructor, and not a mandatory argument for the second one?
Maybe doing 'New MyForm(Null, MyArgs)' is a bit "brain-fucking", but at least
it is not ambiguous.
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
Gambas-devel mailing list