Re: Semantics of vector operations
Larry mused: But we also have the ambiguity with <<'' and friends, so maybe the real problem is trying to make the << and >> workarounds look too much like « and ». Maybe they should be :<< and :>> or some such. Maybe we should be thinking about a more general trigraph (shudder) policy. No! ;-) Or some other kind of "entity" policy. Though I don't think people would be terribly pleased when they see things like: @a »+<<« @b Agreed! Particularly since the "r" one goes on the left, and the "l" on goes on the right. Still, it's potentially a lot less ambiguous, and puts people into the "preprocessing" frame of mind, and would certainly motivate people to move toward editors and terminals that can display: @a »+<<« @b Yes, it would be an excellent motivation in that direction. But, then, so would *not* providing any ASCII-based alternative in the first place. And we wouldn't have to define yet another arbitrary list of mappings. Here, here! I certainly believe that any entity notation must use the "standard" (i.e. HTML and/or Unicode) names for entities. On the other hand, we'd probably have to require a () on the &foo() notation to distinguish it from an &foo; entity. Which would seem to suggest that the Huffman coding is backwards. I expect to use constructs like: my Code $clocks_ref = × far more often than I'd use something like: my Vector $outer = $vec1 × $vec2; especially since I'm already using an OS that makes it trivial to code the latter "properly": my Vector $outer = $vec1 × $vec2; Frankly, I'd *much* rather see: @sum = @a E+< @b; my Vector $outer = $vec1 E $vec2; which at least has the benefit of being consistent with POD notation. (Note that, if we *do* decide to support some kind of ASCII-based entity notation, we really must make sure it's the same in both Perl code and POD mark-up.) Damian
OO inheritance in a hacker style
Hi all.
Sorry if this idea|question has been discussed or has name which i don't know about.
I am not very good at OO but I tried at least 2 times to develop with it though :-)
Last time it was Java. The problem is that when i going to use some 'standard' class
or 3d party class i'd rather to cut off all unnecessary methods (and may be even
properies!),
then adding my own. I know it kills inheritance but it is much more to my Perl habit
of hacking code.
example:
Class a {
method getX;
method getY;
method size;
method area;
method move;
}
I'd like to write
Class myclass : a {
forget method area;
forget method move;
method put;
}
so methods getX, getY, size will be 'inherited'.
Methods 'area' and 'move' will be not present in myclass at all!
so
$a = new myclass;
$a.area()
will return an error.
At some level of inheritance methods area() and move() may be reimplemented again if required.
I see few benefits
1. Much more flexible to build what programmers need. Becouse we have both 'joining'
and 'breaking' around us in real life.
2. Inheritance diagrams may become less in size, showing only what programmer use or
need in classes.
3. probably there are some optimization possibilities (especially for properties)
i see some drawbacks
1. kills traditional OO mainstream, theory and books
2. hard to keep track both for 'added' methods and for 'killed' methods in mind.
3. hard to know if 'killed' method called from the other methods in the class. But
that may be
not a problem if we just declare forget blah, without affecting run-time.
I am very interested what Perl gurus think about it. Even if you consider this as
stupidiest idea ever.
Which is probably true :-)
-Dmitry Dorofeev.
Re: OO inheritance in a hacker style
On Wed, Jan 28, 2004 at 03:18:24PM +0300, Dmitry Dorofeev wrote: > I am not very good at OO but I tried at least 2 times to develop with it > though :-) > Last time it was Java. The problem is that when i going to use some > 'standard' class > or 3d party class i'd rather to cut off all unnecessary methods (and may be > even properies!), > then adding my own. I know it kills inheritance but it is much more to my > Perl habit of hacking code. There's little benefit to explicitly stubbing out inherited methods you don't plan to use, just don't use them. Its not worth screwing up the language's inheritence model with an explicit way to have a subclass not implement its parent's interface. I suspect that if you find yourself only needing a small fraction of your parent's interface often, inheritence might not be the right thing. Consider delegation instead. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
Re: OO inheritance in a hacker style
Dmitry Dorofeev wrote:
Hi all.
Sorry if this idea|question has been discussed or has name which i
don't know about.
I'd like to write
Class myclass : a {
forget method area;
forget method move;
method put;
}
so methods getX, getY, size will be 'inherited'.
Methods 'area' and 'move' will be not present in myclass at all!
so $a = new myclass;
$a.area()
will return an error. At some level of inheritance methods area() and
move() may be reimplemented again if required.
At first, I thought "Hmmm, I'm not sure if this will be useful.
Besides, what would happen in the case of multipile inheri..."
Then, it hit me. A "forget" (or "block", or something similar)
keyword would be great in clearing up confusion with multiple
inheritance.
For instance, in an example like:
class A {
method a_method {}
method common_method {}
}
class B {
method b_method {}
method common_method {}
}
class C is A,B { # Is that right, or am I too java-ed out?
method c_method {}
forget A::common_method;
# or maybe something like: "block A::common_method"
}
Class C would now have access to:
A::a_method, B::b_method, C::c_method, and B::common_method
Of course, roles are another great way to prevent confusion with
multiple inheritance. A good question would be whether something
like "forget" is useful in addition, or whether everyone should
just use roles. :)
- Joe
Re: OO inheritance in a hacker style
Dmitry Dorofeev writes:
> Hi all.
> Sorry if this idea|question has been discussed or has name which i don't
> know about.
>
> I am not very good at OO but I tried at least 2 times to develop with
> it though :-) Last time it was Java. The problem is that when i going
> to use some 'standard' class or 3d party class i'd rather to cut off
> all unnecessary methods (and may be even properies!), then adding my
> own.
Why do you want to cut off theirs?
> I know it kills inheritance but it is much more to my Perl habit of
> hacking code.
Yes, it quite kills inheritance. Say in your example (whose syntax I
will show in this footnote[1]) that you have:
sub foo(a $x) {
print $x.area;
}
Now if you give it a myclass, it's not really an a anymore, because it
doesn't behave like one. Which leads me to believe that you should be
using something besides inheritance.
> example:
>
> Class a {
> method getX;
> method getY;
> method size;
> method area;
> method move;
> }
>
> I'd like to write
>
> Class myclass : a {
> forget method area;
> forget method move;
> method put;
> }
>
> so methods getX, getY, size will be 'inherited'.
> Methods 'area' and 'move' will be not present in myclass at all!
> so
> $a = new myclass;
> $a.area()
>
> will return an error.
> At some level of inheritance methods area() and move() may be reimplemented
> again if required.
>
> I see few benefits
> 1. Much more flexible to build what programmers need. Becouse we have both
> 'joining' and 'breaking' around us in real life.
> 2. Inheritance diagrams may become less in size, showing only what
> programmer use or need in classes.
> 3. probably there are some optimization possibilities (especially for
> properties)
>
> i see some drawbacks
> 1. kills traditional OO mainstream, theory and books
> 2. hard to keep track both for 'added' methods and for 'killed' methods in
> mind.
> 3. hard to know if 'killed' method called from the other methods in the
> class. But that may be
> not a problem if we just declare forget blah, without affecting
> run-time.
So you're saying that if size called area, that area would be called as
though you hadn't forgotten it? Okay, you definitely don't want
inheritance.
It sounds like you're wanting inheritance for code reuse. The Perl 6
way to reuse code is with roles, but assuming that you either don't know
how to use roles, the 3rd party writer didn't use them, or you're in a
language without them (like Java), I would suggest aggregation:
class MyClass {
has A $.a; # turns out that "a" is a keyword in Perl 6
method getX() { $.a.getX }
method getY() { $.a.getY }
method size() { $.a.size }
method put() { ... }
}
The thing is, that when you inherit from a class, you expect the
subclass to behave like the superclass in some extended way (thus the
Java keyword C). Removing methods makes it so the subclass no
longer behaves like the superclass, because methods you'd expect to call
don't exist anymore.
That is not to say, of course, that Perl won't let you do it. It's
Perl, after all :-) [2]
> I am very interested what Perl gurus think about it. Even if you consider
> this as stupidiest idea ever.
> Which is probably true :-)
>
> -Dmitry Dorofeev.
[1] Your code, Perl6-ized:
> Class a {
> method getX;
> method getY;
> method size;
> method area;
> method move;
> }
class A {
method getX() {...}
method getY() {...}
method size() {...}
method area() {...}
method move() {...}
}
> I'd like to write
>
> Class myclass : a {
> forget method area;
> forget method move;
> method put;
> }
[2] Never, ever do this, but just in case:
class MyClass is A {
method put() {...}
method DISPATCH([EMAIL PROTECTED]) {
die "No such method: $DISPATCH" if $DISPATCH eq 'area'|'move';
.$DISPATCH([EMAIL PROTECTED]);
}
}
Luke
Re: OO inheritance in a hacker style
Joseph Ryan wrote:
> Of course, roles are another great way to prevent confusion with
> multiple inheritance. A good question would be whether something
> like "forget" is useful in addition, or whether everyone should
> just use roles. :)
For the record, roles are not a form of multiple inheritence. They're
similar in that both are techniques for code re-use; but there are crucial
differences - for instance, classes call methods; roles merely provide
methods for classes to call.
How about this: allow for two approaches for calling a given method:
implicit (state the object and the method, and leave it up to the class
dispatcher to figure out where the method is to be found - in the class,
one of its roles, or one of its parents) or explicit (state the object,
the method, and the class or role where it will be found). Allow
exclusion of inherited and role methods, but define exclusion strictly in
terms of implicit calls: you're telling the class dispatcher to ignore
that role or parent when searching for candidate methods to call.
Explicit calls would suffer from "brittleness" - that is, if you rename a
role or a class, you'd need to hunt down every instance where one of its
methods is explicitly called and rename it there as well. Implicit calls,
OTOH, would risk incompleteness - exclude an inherited or role method from
a class without providing a valid substitute, and other code may end up
assuming that the class has capabilities that it doesn't.
The danger isn't really in the ability to suppress a method from a given
role or parent; the danger comes from the ability to suppress a method
from _every_ role or parent. A safe alternative to this would be to
define a class method which then turns around and explicitly calls the
inherited or role method that you really wanted; the drawback here is the
poor Huffman encoding involved: writing a method is considerably more
bulky than saying "exclude ..." or "rename ...". You can resolve this
dilemma in two ways (not mutually exclusive): forbid the latter options,
or come up with a more succinct way of handling the former option.
OK; add a trait for methods: call it "from", and require it to take one
parameter: the name of a role or parent. What it does is to automatically
redirect any calls to that method, while removing the need for a code
block. So:
class Parent {
method foo () {...}
}
class Role {
method foo () {...}
}
class Bar is Parent does Role {
method foo () is from Parent;
}
C would be equivelent to C<{return Parent::foo();}>.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
