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
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/
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?
__
Matt Youell - Think
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 wasn't suggesting that Javascript
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
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 open to hearing your reasons
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]
Damian Conway wrote:
* invoke some other hierarchy of automagic methods
(REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or
REINCARNATE
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
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
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
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
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 everyone
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
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
20 matches
Mail list logo
