Re: You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either.
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 me implicitness without unintended post-compile behavior... snip Because templates provide much-needed flexibility in algorithm and class development, C++ programmers don't have to use many of the workarounds that mjd identified. Yes, they have lots of different work arounds. ;) Regardless, a lot of mjd's examples seem dated. He seems to have a clear point to make. I just wish his examples related to any programming I've done in recent memory. I think that OO (and generic programming specifically) reduce his argument. But then again, maybe I'm too entrenched in the C++ mindset. Wouldn't be the first time. snip - Provide a type placeholder in the parameter list (a la C++ function templates) - Provide a type hierarchy for all types (a la Haskell) Let's not forget Java, a less obscure example. I think a type hierarchy makes much more sense than unleashing the hell of templates on Perl. Perl was born in downtown Hell! Bring it on... - Matt
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
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 code-supported (but not enforced) preference that could be relied upon to exist. Of course, a queriable interface could offer the same sort of thing, at the expense of an ugly test repeated everywhere. Selecting a group of standard class methods and insisting that a CPAN upload be compliant with the standard, more restrictive than What The Language Lets You Get Awat With -- that makes sense to me. Perhaps the maintainers of Class::* could converge on a standard API, including a standard name for what the class mechanism in use in a particular instance is. Perhaps there is a solution offering more TMTOWTDI-ability. I've seen a class keyword offered up as a replacement for package dwelling classes. What if *those* classes had stricter rules, but packaged classes where allowed to live on, untouched, in festering sin? But would the game be worth the candle? As a rule, I try not to play games involving candles or other flammables. ;-) - Matt
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
What's the problem again? I mean, really, any OO shop has it's local culture, of what the base classes are and so forth. That pretty much sounds like the problem, in a nutshell. And shop-level is a pretty narrow point of view. What about something that I d/l from the net, where the code is out of my control and unfamiliar? Why can't I reuse code predictably w/o having to figure out how a particular individual/organization allows it? Is there a standard? No. Does there need to be one? I don't see a need for it. What's wrong 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
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
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 alternative. Ah, yes. I've had to deal with that problem several times in the past. The terminology was new to me, however. Has there been a proposed solution? Thanks, - Matt
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
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 http://www.youell.com/matt/ think different - just like everyone else
Re: what I meant about hungarian notation
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 into scalar to the point where it loses its value as a data type that magically converts between numeric and string, as needed, we undo the Great Perl5 Dilution and undecorate references. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? snip We are at the point where there are so many variable types that the dollar sign on their names has become a hollow formality. Again, I'm confused. All I expect from something with a $ is that it's a single value, not necessarily a string or a number. And what if I want to treat a string-ifiable object as an untyped value? Is my var then $ worthy? - Matt
Re: what I meant about hungarian notation
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 notation. Otherwise (as has already been noted), we'd need line noise for each data type. This is the crisis that David N sees... I'm questioning whether there is such a crisis. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? What do you suggest? m_sc_I? (An object member variable that's a scalar named I.) Bah! Actually, you can do that now. I've seen $m_I. Of course, that was from a C++ guy that was just learning Perl. I abhor Hungarian notation. It's the dark side of Lazy. And chances are that if you actually *need* it, your code needs some serious factoring, IMHO. My primary concern in this area is the introduction of forced verbosity. Typing is good for you. It builds strong bodies 8 ways. - Matt
Re: So, we need a code name...
Has anyone suggested Oyster, or is that too obvious? __ Matt Youell - Think different, just like everyone else. [EMAIL PROTECTED] http://www.youell.com/matt/
RE: What will be the Perl6 code name ?!!
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 code name ? even the perl books has some animal to represent the main idea behind... or just for the fun. How about just "O'Reilly" for the code name? ;-) Matt
Re: RFC 161 (v4) Everything in Perl becomes an object.
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 suggestion of others I've opted to freeze rather than withdraw. How might I persuade you to reconsider? I was kind of hoping that this one would get withdrawn as well. Ok, no fair sniping after a freeze. You were warned. It's called email, people! Use it. Jeez... Matt
Re: RFC 161 (v4) Everything in Perl becomes an object.
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 feel Perlish. That's it? Matt
Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors
Damian Conway wrote: * invoke some other hierarchy of automagic methods (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or REINCARNATE
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
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 syntax for doing both.
In C++, you've got two syntaxes for a reason: Objects either live on the
stack or the heap. So each syntax has a direct under-the-hood correlation to
the different ways of storing an object. I Perl, we don't really care where
the object gets stored so it's not as natural to make the distinction.
Perhaps the shift-on-the-fly usage could explicitly use a typeglob syntax
and declare it to be associated with Dog?
my Dog *spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
Matt
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
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 problem you are trying to solve is long type-names
(which is a bazzar thing to find in perl anyway). I just think that there
are better ways of skinning that cat.
I think the main idea here is this: being allowed to say what you mean
without repeating yourself.
Matt
Re: RFC 161 (v2) OO Integration/Migration Path
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 responsibility closer to the basic data structures (currently scalar, list, and hash). - Allow customization of these structures by the user, though inheritance. - Reduce or eliminate the need for new keywords in Perl itself, since the basic data structures can be extended as needed. - Maintain a migration path for Perl 5 (so I can have all of this without touching my existing code). I shudder to think of something that prevents simple variable accesses and instead requires verbose method calls. That doesn't seem to be making anything easy. Ditto. Accessing data doesn't change. I'm not suggesting accessors be added to scalars. Rather, I'm suggesting that scalars be responsible for knowing their type, rather than Perl being responsible for that. Methods like 'asInt()' are intended to act as a switch that gets flipped so the scalar knows what type it is supposed to be. Optionally, they could also act as a cast mechanism when used as an rvalue. An overloadable cast mechanism at that. Do you mean that when we write: my int $intVal = 0; it gets turned into OO stuff? Or do you mean that we won't be writing my int $intVal = 0; any more? I don't like the latter option. It would seem to require more typing to allow something that a minority of people will use. Originally I was trying to avoid explicit typing through new keywords, like 'int'. So the latter option would have been the case. But after Nathan Wiger's reply to my RFC, I realized that either syntax would work. Under one scenario, 'int', as in your example, would simply be the name of a factory function, so that: my int $intVal = 0; could be equivalent to: my $intVal = Scalar-int(0); And with no more typing required than before. Matt
