Well, my hope is somehow we can get types to be a bit more implicit
than the usual mess most people are used to.
I have grave concerns about 'implicit' typing. In my experience DWIM-style
typing can lead to serious hair pulling and long debug sessions over simple
errors. Now, if you can give
What if you want multiple constructors with redundant code, et cetera --
there is flexibility.
You could get that same flexibility from a mandated new(). If you don't want
to support new, overload it so that it does nothing. Or maybe that could be
the default behavior. The major benefit being a
an implicit
new() method that is overloadable? Is this really *that* complicated? Maybe
I'm not getting the Big Picture.
matt youell
http://www.youell.com/matt/
think different - just like everyone else
MI thing, but now it's sounding like a constructor bubbling scheme, like
in
C++, etc.
Right. Perl doesn't have it by default, and *can't* have it
except under certain rather strict constraints, e.g. when all
players are playing by the Class::Struct rules, or some other
more elaborate
Forgive my woeful ignorance Could someone define data aggregation by
inheritance? From John's original mention I thought this was some oblique
MI thing, but now it's sounding like a constructor bubbling scheme, like in
C++, etc.
Thanks!
matt youell
snip
sane indentation by making it part of the language, Perl is a
language that enforces a dialect of hungarian notation by making
its variable decorations an intrinsic part of the language.
But $, @, and % indicate data organization, not type...
What if, instead of cramming everything
But $, @, and % indicate data organization, not type...
Actually they do show type, though not in a traditional sense.
Organization - type is semantic oddery, but they do keep our heds
straight
about what's in the variable.
Sure. But my point was that Perl's use of $ isn't Hungarian
Has anyone suggested Oyster, or is that too obvious?
__
Matt Youell - Think different, just like everyone else.
[EMAIL PROTECTED] http://www.youell.com/matt/
Red Had
Version 7 (Guinness)
Version 6.2 (Zoot)
Version 6.1 (Cartman)
Version 6.0 (Headwig)
Version 5.2 (Apollo)
Version 5.1 (Manhattan)
Version 5.0 (Hurricane)
Version 4.2 (Biltmore)
Version 4.1 (Vanderbilt)
Version 4.0 (Colgate)
Nothing like consistency. =)
What will be the Perl6
On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote:
Not an awful lot was said once this RFC was condensed down to
"Everything
becomes an object". I believe some implementation and conceptual
hurdles
exist which have discouraged more serious discussion. At the
On Wed, Sep 27, 2000 at 12:16:36PM -0700, Matt Youell wrote:
I open to hearing your reasons. The biggest reason it wasn't withdrawn
is
because someone said "hey don't do that, here's why". So give me a "why"
already...
It doesn't feel right to me. It doesn't fe
Damian Conway wrote:
* invoke some other hierarchy of automagic methods
(REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
Right now, the default behavior of perl is that un-initialized variables
are automatically undef. It would be weird to have to do explicit
assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable
mainstream OO languages go). It looks like Dog could be a type of String
subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
As with the above, the
I've read over 161 again and I'm starting to see areas where I can clarify
things greatly. I apologize for the confusion. I'll make mods to the RFC in
the near future, after I get more feedback from you all.
Here are my goals as they probably should have been stated in the RFC:
- Concentrate
15 matches
Mail list logo
