RE: A12: subtypes that lack methods or roles

[Dov Wasserman]

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