> 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
with something simple, like saying all classes have 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 elab
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!
____
> > 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 Hungari
> 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 into
Has anyone suggested "Oyster", or is that too obvious?
__
Matt Youell - "Think different, just like everyone else."
[EMAIL PROTECTED] http://www.youell.com/matt/
> What about leaving the flora aund fauna and using a name
> like they call ships?
> They always got names of females or towns...
>
> I suggest:
>
> PISA
>
Um... that sounds perilously close to "Piece Of". Am I alone on this one?
____
> 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...
> On Wed, Sep 27, 2000 at 12:31:25PM -0700, Matt Youell wrote:
> > Would something less esoteric like Javascript be a better comparison?
>
> Not really. Perl and JavaScript have very little in common, despite what
> members of this list would like to do.
>
I w
On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
>> I'd cite ruby as an indication that it shouldn't have to inflict any
>> performance hit
>*boggle*. That's classic. Ruby *is* a performance hit.
Would something less esoteric like Javascript be a better comparison?
Matt
> On Wed, Sep 27, 2000 at 09:53:03AM -0700, Matt Youell wrote:
> > Ok, no fair sniping after a freeze. You were warned. It's called email,
> > people! Use it. Jeez...
>
> Never too late to withdraw, sir. [1] The less crap we make Larry wade
through,
> the better.
I
> > 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
Unless I hear compelling arguments to the contrary, I'll be withdrawing RFC
161 on Tuesday due to lack of interest.
Matt Youell
[EMAIL PROTECTED]
> goes? Your logic suggests that I'd never want to meddle in the base's
> implementation.
What happens when the base classes' author finally fixes the problem you
wrote around (and incidentally changes touchy implementation details in the
base)? What happens someday when you can't see the implem
> 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 sy
Perhaps there is some way to allow for both syntaxes? For example, in C++ I
can say:
string str();
or:
string* str = new string();
Depending on my needs.
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog obj
> 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, th
> Here's hoping I don't have to prove that, and Larry will just reject
> this proposal outright. :)
I would hope that *no* proposal would be rejected "outright", otherwise we
might miss some real opportunities.
Here's hoping that you *do* have to prove what you're saying. That would
give everyon
> I just want to hit this point a little more, to make sure we're actually
> in agreement.
Ok, ok... sorry about this. I've been hammering away at a stubborn gray area
and now I'm seeing that "duh!" it's all right there. Yes, of course 'int'
would be a subclass of Scalar. You know, it's silly...
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 re
> Great. My point I was trying to drive at was that:
>
>my int $x = 5;
>
> Could turn around and do something different than asInt(). All stores
Got it. And sure, why not? Pay the overhead when you absolutely need to, and
no sooner. The core idea (for me) is to avoid wasting resources on a
me
> Arg! You beat me to it. :-) This was the next RFC on my list.
Nate, if I had known that, I would gladly have let you take the arrows. =^)
> However, nobody should ever have to call something like $n->NUMBER or
> $n->asInt if they don't want to. And they definitely shouldn't have to
> know the
25 matches
Mail list logo
