On Sun, 2007-07-22 at 22:24 +1000, Rhythmic Fistman wrote:
> On 7/22/07, skaller <[EMAIL PROTECTED]> wrote:
>
> > Well, perhaps it is a bug, but currently, a _ctor_* fuction
> > for an abstract type must be defined in the same scope
> > as the abstract type.
>
> Well, that's probably how you should lay about. I stumbled
> across this one because I didn't know about the _ctor_*
> notation and I'd been writing awkwardly named functions
> to replace them. My first attempt with _ctor_ happened to be in
> a different scope and I thought I'd found a bug, however my
> distilled version compiled. All is now clear.
>
> I think I asked something similar once about the get_blah
> functions. Same thing?
Yes, for the same reason: the notation
o.meth
uses Koenig lookup, aka DNL or Dependent Name Lookup.
The search is restricted to the scope the type of 'o' is
defined in. This lets you write:
type myobj = "mine";
fun get_x: myobj -> int = "$1.x";
simulating members of myobj type.. well we can't nest
these members IN that type, but the least we can do
is insist they're defined next to it.
Same idea with 'constructors' of a type: they should
be considered strong associated with the type.
However the code doing the two different lookups is
quite different (and not necessarily consistent.. :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
