--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
> : hmm... lexical properties....I've read the rest of the message,
> : and I see how this could be a problem. Just to be clear on it,
> : what exactly would it mean for a property or trait to be lexical?
> : If a value or container with that aspect gets passed out of that
> : scope, what happens?
>
> It would mean that that aspect becomes unnameable, even if a
> different lexical name looks like it. (But note that exportation
> can cause two distinct lexical scopes to share the same name.)
To quote a better man than me, "ow, me noggin."
Do you mean unreference-able by name?
And "exportation"???
> : Wouldn't an object efectively provide a virtual "scope" of its own?
>
> Depends on what you mean by effective. There's a sense in which the
> object knows nothing about the properties that are going to be bound
> to it someday, or whether there might be two conflicting properties
> of the same name. There is the danger of ad hoc polymorphism.
Don't you just love the way the Greek "polymorphism" just comfortably
sidles up to the literal Latin "ad hoc"? :) Almost makes me feel like
I was back in college, staying up way too late talking about the nature
of reality, except that this is both more "concrete", if you will, and
usually more confusing, lol.
What I mean is (I guess) that there should only be one $o.bar, and it
sounds like you're saying that's not the case. Please fix my bleeding
brain on this one?
> : Maybe the syntax looks something like this:
> :
> : class Foo has Scalar bar is rw = undef; # suplies a default
>
> Well, it's "does" to incorporate a role, but again, you generally
> wouldn't apply a property to a class at compile time.
You say "again". :)
As a general apology to anyone besides me who might be inconvenienced
by it, my mail is on a bounce or three before I get it, and may go out
as strangely, so I suspect you recieved my second message before my
first. You certainly responded to that one first.
> : That would allow you to add the property to the class with a
> : default value at compile time, wouldn't it? Then you could modify
> : objects:
> :
> : my $o = Foo.new;
> : $o.foo but= "stuff";
>
> That'd be adding an anonymous property to the foo attributes. You
> want:
>
> $o but= foo("stuff");
Ah! Okie.
> : It would also make it inherently class scoped, and would fail to
> : compile if someone in another module had already declared a
> : property bar. Right?
>
> You don't want properties inherently class scoped. Except when you
> do.
Right. I'm with you.
> : > Or maybe we can tag property names with the scope in which
> : > they're declared somehow.
> :
> : o. That's hairy, isn't it?
> : Yes, I think it would be useful...but what's the upshot? The value
> : of $o.foo is dependent on scope? Hmm.... My first reaction was to
> : frown and shudder, but maybe that's short-sighted. Any lexical
> : variable's value is always dependent on scope.
> :
> : our $foo = 1;
> : { my $foo = 2;
> : print $foo; # 2
> : }
> : print $foo; # 1
> :
> : I'm just not sure how I like the idea of that applying to
> : properties.
> :
> : our $o = Foo.new();
> : $o.foo but= "global?";
> : dostuff::with($o); # module scope, different value?
> :
> : Wouldn't that utterly mangle the principle of least surprise?
>
> The principle of least surprise is also utterly mangled by accidental
> polymorphism. We can prevent that by complaining when we detect the
> attempt to declare or import two different properties of the same
> name.
>
> Larry
Which does make better sense. :)
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
