I was having that problem too going over S09. It seems like we need to get
the glossary together like Uri was saying that we can have a controlled
language for creating the documents. If we dont have one already, I suggest
we start one.
Jordan
On 7/11/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
S02 and S06 discuss containers quite a bit. They say things like:
"The is NAME (DATA) syntax defines traits on containers and
subroutines" -S06
"A variable object may itself be bound to a container type that
specifies how the container works without necessarily specifying
what kinds of things it contains." -S02
>From this, I gather that it is our intention that containers have common
behaviors. In working on the Functions document (nominally S29), I've
come across some functions (such as C<each>, defined in S03), which are
not tied to specific container types, and probably want to be defined in
terms of the common container class.
Is it OK for me to arm-wave a C<Container> class which can stand in for
any container type? For example:
our List multi Container::each(Container [EMAIL PROTECTED])
Thoughts? Bad plan? I understand that there's some ambiguity here... it
might even be that Container is a role, not a class, or might be an
arm-wavy thing that abstracts some implementation details. I'm not
concerned about that just yet, I just need something to call these
things. Otherwise I have to put one definition for each of these
functions into the section for each type of container (too many
eaches...). I don't even have a section for things like Seq and Buf yet,
and I'd rather not if I don't have to.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
