Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote: On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. Sounds kind of like Linus's opinion of close-source modules. If they exist and work, he's not going to break them, but he's not going to do *anything* to specially support them. I mostly agree, but I'm not talking about the *license* of the code. I don't think that's clear to everyone reading this thread, so I think I should clarify. Regardless of the license, the author of a class or module should not be able to close off that class or module from people using that class or module who want to poke around in its guts at runtime, regardless of the license or availability of the source code. Allowing authors to say This is my namespace and you cannot touch it or This is my class and you cannot touch it or derive from it or decorate it or apply roles to it is silly, because they'll do stupid and wrong things that the rest of the world will have to work around forever, regardless of the license of their code. By all means write efficient code and well-encapsulated code and document your interfaces and intentions appropriately, but if you want to write generic and reusable code, don't optimize for situations which you can't possibly have profiled because no one has written the code for them yet. We should not encourage that. -- c
Re: What the heck is a submethod (good for)
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a cascade method syntax would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated method in
a superclass was called. Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Re: What the heck is a submethod (good for)
All~
On 10/13/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a cascade method syntax would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated method in
a superclass was called. Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
I have always wondered about the absence of these. CLOS has them and
they look quite useful. Was it an intentionaly decision to omit this
type of multi method?
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: What the heck is a submethod (good for)
On Oct 13, 2005, at 9:47 AM, Matt Fowles wrote:
On 10/13/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a cascade method syntax
would
be better for that:
post method BUILD($foo, $bar) { ... }
pre method DESTROY() { ... }
Cascade methods would be called (before|after) the indicated
method in
a superclass was called.
I don't think there is a need to restrict it to the wrapping
superclasses methods only, there is no reason that you could not also
have them wrap a local method too if you wanted.
This might actually be a legitimate use for a submethod too.
pre method foo () { ... } # this is inherited
submethod foo () { ... } # this is not inherited
post method foo () { ... } # this is inherited
I could see this construct being quite useful in a Template Method
pattern sort of way.
Their return values would probably be thrown
away. I think they might actually be a sort of syntactic sugar for
inserting `call` in the method body, but that's an implementation
detail, really...
I have always wondered about the absence of these. CLOS has them and
they look quite useful.
CLOS has before, after and around method qualifiers actually.
AFAIK, the return values of these methods are thrown away too, as
Brent suggests.
One thing to keep in mind is that CLOS has generic functions instead
of the usual methods-attached-to-a-class scheme. It also has no
(simple) means of calling superclass methods and capturing the return
values (at least AFAIK, I am sure someone has hacked the abilities,
but I don't think it is part of the spec). The method qualifiers were
added to CLOS to allow for this kind of behavior.
Since Perl 6 does not suffer from this same issue, method qualifiers
are not *needed* like they are in CLOS. That said, they are a nice
bit of syntactic sugar (as Brent points out).
Maybe this could be done with traits?
method BUILD ($foo, $bar) is post { ... }
method DESTROY () is pre { ... }
Or possibly with some kind of name-mangling:
method BUILD:post ($foo, $bar) { ... }
method DESTROY:pre () { ... }
Stevan
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
I think this is an opportune time for me to express that I think the ability to close-source a module is important. I love open source, and I couldn't imagine writing anything by myself that I wouldn't share. But in order for Perl to be taken seriously as a commercial client-side language, it must be possible to close the source. I started writing a game with a few friends last year, and as we were picking our implementation strategy, using Perl as the primary sequencing engine for non-time-critical tasks was immediately discounted when I commented that anybody can look at your perl source if they want to. I'd be interested in finding out how this is reasonably feasible for, given that you just said a disassembler for Parrot is going to be relatively simple due to the level of introspection Perl is going to require. Of course, given that Parrot is the ultimate interoperability swiss army knife, one could envision a language without the introspection Perl requires (such as C) that would target Parrot quite nicely. (Isn't Carrot the name for this push? I haven't kept up with the Parrot list.) Then, disassembling that bytecode back to its original form becomes much less desirable. Of course, there is no argument there for allowing closed-source *modules*, just complete applications. But I'm sure you could fish one out involving dynamic loading, or modding, or whatever you want to call it. The argument that was made was for closing modules, not applications. Specifically, a DB vendor might be more comfortable providing a DBD for their product(s) if they could close the source.
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, Oct 13, 2005 at 03:01:29PM -0400, Rob Kinyon wrote: I think this is an opportune time for me to express that I think the ability to close-source a module is important. I love open source, and I couldn't imagine writing anything by myself that I wouldn't share. But in order for Perl to be taken seriously as a commercial client-side language, it must be possible to close the source. I started writing a game with a few friends last year, and as we were picking our implementation strategy, using Perl as the primary sequencing engine for non-time-critical tasks was immediately discounted when I commented that anybody can look at your perl source if they want to. I'd be interested in finding out how this is reasonably feasible for, given that you just said a disassembler for Parrot is going to be relatively simple due to the level of introspection Perl is going to require. When I added the original encryption mechanism for perl (in early perl 3 days) I knew that it would not be an absolute ban to stop people from recreating my company's original source (and that was long before B::Deparse came along, of course). I certainly knew how to beat the encryption; and anyone with half a clue would know that it could be beaten. (Clue: perl has to be able to read the unencrypted code. It wasn't hard to find the right place in the perl source to insert a print statement that would dump out code that had been decrypted.) However, anyone who took the effort to recreate that source from encrypted form would *know* that any use of that decrypted source was not authorized by the copyright owners. This was considered by that company to be an adequate protection. Any infringement that did occur would clearly be a deliberate misuse and could be prosecuted with a reasonable assurance of success. (No such infringement was ever found - either anyone who considered it decided it would be too much work, or no-one was interested enough to consider it, or quite possibly there were one or more instances where it was decrypted for the challenge of beating the encryption but not in any way that lead to an obvious competitive misuse.) Just because you can't make locking perfect does not mean it has no value. --
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote: Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. In theory I agree, and I hope that will be the defacto way of doing it, but if perl 6 gets compiled portably to many different bytecodes (which it seems like it will) someone somewhere will write a backend which allows people to encrypt, and people will use it. I think this is something we need to accept, even if it isn't something we like. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpDwgwZYGNe6.pgp Description: PGP signature
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote: On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote: Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. In theory I agree, and I hope that will be the defacto way of doing it, but if perl 6 gets compiled portably to many different bytecodes (which it seems like it will) someone somewhere will write a backend which allows people to encrypt, and people will use it. I think this is something we need to accept, even if it isn't something we like. I don't care if people encrypt their code. I don't have to use it. I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. No Java final, unless you're the one running the program. -- c
Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. Sounds kind of like Linus's opinion of close-source modules. If they exist and work, he's not going to break them, but he's not going to do *anything* to specially support them. -- Chip Salzenberg [EMAIL PROTECTED]
What the heck is a submethod (good for)
Okay, I seriously have to see an example of a submethod in use. BUILD
etc. don't count. Why? Because:
class Foo {
method BUILD () { say foo }
}
class Bar is Foo {
submethod BUILD () { say bar }
}
class Baz is Bar { }
Foo.new; # foo
Bar.new; # foo bar
Baz.new; # foo bar
If the submethod property of BUILD were actually doing anything, then
we should expect it to read like this:
Foo.new; # foo
Bar.new; # bar
Baz.new; # foo
So I don't see how the constructor is a submethod[1]. And I can't
come up with any examples of where I would want to use a submethod.
Can someone else?
Luke
[1] Yes, yes, I understand that .new is calling BUILDALL, which is
then calling the BUILDs individually. I'm saying that the fact that
BUILD is a submethod isn't changing anything one bit.
Re: What the heck is a submethod (good for)
Luke wrote:
Okay, I seriously have to see an example of a submethod in use.
class Driver::Qualified {
method drive {
print Brrrm brrrm!
}
}
class Driver::Disqualified is Driver {
submethod drive {
die .name(), not allowed to drive
}
}
class Driver::Requalified is Driver::Disqualified {}
my Driver $preDUI = Driver::Qualified.new();
my Driver $perDUI = Driver::Disqualified.new();
my Driver $postDUI = Driver::Requalified.new();
$preDUI.drive(); # calls Driver::Qualified::drive
$perDUI.drive(); # calls Driver::Disqualified::drive
$postDUI.drive(); # calls Driver::Qualified::drive
Damian
Re: What the heck is a submethod (good for)
On Thu, Oct 13, 2005 at 05:42:31 +1000, Damian Conway wrote:
Luke wrote:
Okay, I seriously have to see an example of a submethod in use.
class Driver::Qualified {
method drive {
print Brrrm brrrm!
}
}
class Driver::Disqualified is Driver {
submethod drive {
die .name(), not allowed to drive
}
}
class Driver::Requalified is Driver::Disqualified {}
This is not obvious that the behavior is modified, and it makes
other subclasses, like Driver::Disqualified::Drunk and
Driver::Disqualified::Suicidal causes the above design choice to
make you either update Driver::Requalified and Driver::Disqualified
to regular methods, or duplicate code in Driver::Disqualified::*.
That much aside, this is not a real world example. Can you try to
think of one that really applies? Looking at my past $work projects
I can't think of a single instance where submethods would help me
code better. On the other hand roles mixin inheritence, private
attributes that don't conflict with other private attributes of the
same name, better polymorphism, better introspection, and a
metamodel could have helped a lot in many places.
This has even more implications with closed classes to which you
don't have source level access, and if this can happen it will
happen - i'm pretty sure that some commercial database vendors would
release closed source DBDs, for example.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: : neeyah!
pgpb15yuOsYCY.pgp
Description: PGP signature
Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote: This has even more implications with closed classes to which you don't have source level access, and if this can happen it will happen - i'm pretty sure that some commercial database vendors would release closed source DBDs, for example. Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. -- c
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On 10/12/05, chromatic [EMAIL PROTECTED] wrote: On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote: This has even more implications with closed classes to which you don't have source level access, and if this can happen it will happen - i'm pretty sure that some commercial database vendors would release closed source DBDs, for example. Closed classes should not exist. At least, they should only exist if the person *running* Perl 6 wants them to exist -- never if merely the class writer wants to close them. I'm not sure y'all are talking apples and apples. Yuval is talking about lack of source-level access and the class being closed. I'm not quite sure how we end up with a lack of source-level access, particularly as that locks me, the user of your module, into one specific P6 interpreter (presumably Parrot). Given the work that Autrijus and company have been doing with PIL and Pugs in general, closing the source (presumably by releasing Parrot bytecode) isn't going to really work. (Plus, I can't imagine that a reverser for Parrot code is going to be that hard to write.) Furthermore, is releasing just the Parrot bytecode going to work in multi-lingual apps? Aren't there optimizations that may not be appropriate before all the languages are known? (I'm completely out on a limb, here.) That said, I agree with chromatic closing (or finalizing) a class should be the action of the consumer, not the producer. Maybe the producer could signal his/her desire to close the class when some phase is finished. That would mean the consumer could either modify the class before that phase is finished and/or the consumer could intercept the request for finalization. Alternately, maybe you have a pragma that says Finalize all classes unless I specify that it should remain open. Maybe, we need a negation for close? keep_open? Rob
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On 10/12/05, Rob Kinyon [EMAIL PROTECTED] wrote: Plus, I can't imagine that a reverser for Parrot code is going to be that hard to write. Disassembling register machine code is significantly more difficult than disassembling stack machine code. That said, if the level of introspective capabilities is high, then disassembling is probably not hard. As far as I know, keeping introspective capabilities high is a major Perl goal :-) Alternately, maybe you have a pragma that says Finalize all classes unless I specify that it should remain open. That's the plan, where the pragma is only available before any modules are loaded, IIRC (this keeps modules from closing themselves off). I think this is an opportune time for me to express that I think the ability to close-source a module is important. I love open source, and I couldn't imagine writing anything by myself that I wouldn't share. But in order for Perl to be taken seriously as a commercial client-side language, it must be possible to close the source. I started writing a game with a few friends last year, and as we were picking our implementation strategy, using Perl as the primary sequencing engine for non-time-critical tasks was immediately discounted when I commented that anybody can look at your perl source if they want to. Of course, there is no argument there for allowing closed-source *modules*, just complete applications. But I'm sure you could fish one out involving dynamic loading, or modding, or whatever you want to call it. Luke
