RE: A12: subtypes that lack methods or roles
Dov Wasserman wrote: > It's a valid question in general, but since you're designing this > functionality from the ground up (and not retro-fitting it in to > existing code), wouldn't the better approach be to create a non-GUI > HList class, and a GUI subclass that adds the indicator methods? Or > even better, less tightly coupled and in line with the MVC pattern, an > HListModel class and a HListWidget class that composes an HListModel > within it. Well, yes. But I wasn't mentioning this as "the best way" to handle this particular case; rather, I was using this particular case to illustrate the more general question. How do I remove functionality from a class or role that someone else put together? = Jonathan "Dataweaver" Lang __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash
Re: A12: subtypes that lack methods or roles
On Fri, 2004-04-23 at 21:44, Jonathan Lang wrote: > OK: I'm planning on creating a widget which must not make use of any of > the indicator functionality of the HList; I don't just want to not use the > functionality - I want to have its use forbidden (letting the optimizer go > ahead and toss out the indicator role). So I'd like to create a subtype > of HList which exceises that functionality. I think you're thinking of this backwards. Don't subclass HList. Create a new class that doesn't subclass anything and compose the appropriate roles into it. Provided the library designers have done their job and *ask for the proper role in function and method signatures, not a specific class*, you're groovy. Now I could be wrong about your intent, but the question "How do I subclass a class to *remove* functionality?" is the kind of "Yeah, it hurts when you do that" situation role-based composition try to avoid. If you have all of the pieces, put them together in a way you find most pleasing. -- c
RE: A12: subtypes that lack methods or roles
It's a valid question in general, but since you're designing this
functionality from the ground up (and not retro-fitting it in to existing
code), wouldn't the better approach be to create a non-GUI HList class, and
a GUI subclass that adds the indicator methods? Or even better, less tightly
coupled and in line with the MVC pattern, an HListModel class and a
HListWidget class that composes an HListModel within it.
-Dov Wasserman
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 24, 2004 12:44 AM
To: [EMAIL PROTECTED]
Subject: Re: A12: subtypes that lack methods or roles
Larry Wall wrote:
> Jonathan Lang wrote:
> : How would I declare a subtype of a class which messes with the
> : dispatching mechanism to exclude certain methods and/or roles from
> : it?
>
> Er, uh...tell you what. Why don't you provide some sample code to
> go with your question, and we'll just tell Dan to make it work. :-)
This goes along with my other thread about nested roles. In Perl/Tk -
specifically HList, there's a bunch of methods, including:
add, addchild, delete, headerCreate, headerConfigure, headerCGet,
headerDelete, headerExists, headerSize, indicatorCreate,
indicatorConfigure, indicatorCGet, indicatorDelete, indicatorExists,
indicatorSize, itemCreate, itemConfigure, itemCGet, itemDelete,
itemExists, ...
In perl 6, I'd be tempted to handle it something like this:
class HList {
method add {...};
method addchild {...};
method delete {...};
# things relating to multicolumn lists
does role header {
has Int $.columns;
method headerCreate {...};
method headerConfigure {...};
method headerCGet {...};
method headerDelete {...};
method headerExists {...};
method headerSize {...};
};
# things relating to the icon next to each tree entry
does role indicator {
has Flag $.indicator;
method indicatorCreate {...};
method indicatorConfigure {...};
method indicatorCGet {...};
method indicatorDelete {...};
method indicatorExists {...};
method indicatorSize {...};
};
# things relating to individual "cells" in the list
does role item {
method itemCreate {...};
method itemConfigure {...};
method itemCGet {...};
method itemDelete {...};
method itemExists {...};
};
...
};
OK: I'm planning on creating a widget which must not make use of any of
the indicator functionality of the HList; I don't just want to not use the
functionality - I want to have its use forbidden (letting the optimizer go
ahead and toss out the indicator role). So I'd like to create a subtype
of HList which exceises that functionality. It's a subtype of HList in
the sense that we're removing functionality in order to get there;
however, we're removing functionality by saying that, in effect, this
subtype does _not_ do the indicator role.
So when the resulting thing attempts to call the indicatorCreate method,
it first looks at the class methods, and doesn't find anything; it then
looks at each of the roles, _except for the indicator role_. It doesn't
find anything. It then looks at any inherited methods, etc., and
ultimately doesn't find the method. It then throws an exception to alert
the programmer that he's trying to use a routine that he's not supposed to
use.
So how to tell the subtype(?) to disregard the indicator role? While
we're at it, I'd also like to remove the addchild method, since I don't
want this thing to be used to create hierarchal structures - I'm looking
for the tabular data capabilities in this case.
=
Jonathan "Dataweaver" Lang
Re: A12: subtypes that lack methods or roles
Larry Wall wrote:
> Jonathan Lang wrote:
> : How would I declare a subtype of a class which messes with the
> : dispatching mechanism to exclude certain methods and/or roles from
> : it?
>
> Er, uh...tell you what. Why don't you provide some sample code to
> go with your question, and we'll just tell Dan to make it work. :-)
This goes along with my other thread about nested roles. In Perl/Tk -
specifically HList, there's a bunch of methods, including:
add, addchild, delete, headerCreate, headerConfigure, headerCGet,
headerDelete, headerExists, headerSize, indicatorCreate,
indicatorConfigure, indicatorCGet, indicatorDelete, indicatorExists,
indicatorSize, itemCreate, itemConfigure, itemCGet, itemDelete,
itemExists, ...
In perl 6, I'd be tempted to handle it something like this:
class HList {
method add {...};
method addchild {...};
method delete {...};
# things relating to multicolumn lists
does role header {
has Int $.columns;
method headerCreate {...};
method headerConfigure {...};
method headerCGet {...};
method headerDelete {...};
method headerExists {...};
method headerSize {...};
};
# things relating to the icon next to each tree entry
does role indicator {
has Flag $.indicator;
method indicatorCreate {...};
method indicatorConfigure {...};
method indicatorCGet {...};
method indicatorDelete {...};
method indicatorExists {...};
method indicatorSize {...};
};
# things relating to individual "cells" in the list
does role item {
method itemCreate {...};
method itemConfigure {...};
method itemCGet {...};
method itemDelete {...};
method itemExists {...};
};
...
};
OK: I'm planning on creating a widget which must not make use of any of
the indicator functionality of the HList; I don't just want to not use the
functionality - I want to have its use forbidden (letting the optimizer go
ahead and toss out the indicator role). So I'd like to create a subtype
of HList which exceises that functionality. It's a subtype of HList in
the sense that we're removing functionality in order to get there;
however, we're removing functionality by saying that, in effect, this
subtype does _not_ do the indicator role.
So when the resulting thing attempts to call the indicatorCreate method,
it first looks at the class methods, and doesn't find anything; it then
looks at each of the roles, _except for the indicator role_. It doesn't
find anything. It then looks at any inherited methods, etc., and
ultimately doesn't find the method. It then throws an exception to alert
the programmer that he's trying to use a routine that he's not supposed to
use.
So how to tell the subtype(?) to disregard the indicator role? While
we're at it, I'd also like to remove the addchild method, since I don't
want this thing to be used to create hierarchal structures - I'm looking
for the tabular data capabilities in this case.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
Re: A12: subtypes that lack methods or roles
At 6:12 PM -0700 4/23/04, Larry Wall wrote: On Fri, Apr 23, 2004 at 03:07:23PM -0700, Jonathan Lang wrote: : How would I declare a subtype of a class which messes with the dispatching : mechanism to exclude certain methods and/or roles from it? Er, uh...tell you what. Why don't you provide some sample code to go with your question, and we'll just tell Dan to make it work. :-) No problem. Throwing an exception counts as working, right? :-P -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: A12: subtypes that lack methods or roles
On Fri, Apr 23, 2004 at 03:07:23PM -0700, Jonathan Lang wrote: : How would I declare a subtype of a class which messes with the dispatching : mechanism to exclude certain methods and/or roles from it? Er, uh...tell you what. Why don't you provide some sample code to go with your question, and we'll just tell Dan to make it work. :-) Larry
A12: subtypes that lack methods or roles
How would I declare a subtype of a class which messes with the dispatching mechanism to exclude certain methods and/or roles from it? = Jonathan "Dataweaver" Lang __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash
