Re: [Pyx-devel] design/arg.tex

[Andre W. <And...@Ph...>]

Hi,

On 25.02.02, Andre Wobst wrote:
> > Ok, this is certainly an advantage of such an approach (but see my
> > comment above), though it is not perfectly object oriented. Maybe,
> > we need compound objects, which glue together some text or path with
> > style properties. I already though about something like this for
> > paths. But this is just an idea.
>=20
> You're right, that that solution is not perfectly object oriented. The
> main advantage of not having objects there is the easy way of writing
> it. And --- in that sense --- the tuple lists are just the glue. And I
> do have another strong argument (I think). Think about a string having
> some substitution parameters (%), followed by a % and then a tuple. It
> is exaclty the same construction, isn't it?

I do have some additional comments about that. They show, that it is
not that easy with that case of a routine taking a string together
with properties of that very string.

First of all, I was thinking along the line of ``%'' and came up with
just an idea, how a nice design would be (although it would lead to a
"new language", which is not a possible solution ... I do remember
very well, that we once tried to make PyX look more like gle, but
fortunately we gave up).

But still, consider to write "the glue" (combining "text" and it's
attributes) like a string with substitutions using an alleged ``@''
operator. We could write:
        "text"
        "text" @ fontsize.small
        "text" @ (fontsize.small, halign.center, )
... and so on. I'm quite puzzled about that. (BTW: We would need
something like ``\makeatoperator'' ... but while in TeX you make that
change global, you would need ``\WithinExpression{\makeatoperator}''.
Anyway, it is funny that you can switch the type class of your
characters in TeX.)

Ok, now I do come to a real problem we do have to consider anyway.
Suppose you do have some kind of forming a text-with-attribute. What
about a routine reply(), which wants to add a "Re: " in front of a
subject? Consider, that the subject already have a attribute supplied
by the user (like a("red")), but this subject subroutine add's first
some other text (the "Re: ") and than another attribute (like a color
blue). Ok, the result would/should look like
        <a color=3D"blue">Re: <a color=3D"red">spam</a></a>.
What the main point here is, that this text-with-attribute has to
behave like a text itself in order to get the add working without
considering, that we do not have a text, but a text-with-attribute.

Finally (for the moment), I would suggest to think about a class
combine. I do not know, if this can be done without side effects. But
it should work the following way:

--  combine("spam", a("red"))
    out of that we need to be able to create the correct output (e.g.
    performing the attribute change a("red") to "spam" (whatever
    that attribute change has to be worked out in the end)

--  combine(type/class - instance)
    should be allowed for any argument

--  combine(type/class, a("red"), a("blue"))
    should just be able

--  combine(type/class - instance, <something>)
    should behave like the type/class - instance itself. This would
    mean, the attributes are just attributes (they do not modify the
    behavior of the type/class - instance against operators).

--  combine("spam", a("red")) + "eggs"
    (and other those constructions) should just work like expected.
    I do think, this case needs to be subject of detailed discussion,
    how it should work. I do not yet know, what type of object that
    thing is. For the moment I guess we would need a encapsulation
    class for that:
    combineop(op_add, combine("spam", a("red")), "eggs")

    --  combineop(<op>, type/class - instance, type/class - instance))
        should behave like using the appropriate operator for the two
        classes supplied.
        <op> may not be any allowed for all operators for the moment.
        As long as we have only strings and lists (paths?) as
        type/class - instances, we do not need a multiply operator
        (just as an example).

--  combine("spam") < combine("eggs")
    (and other those constructions) should just call the appropriate
    operator for "spam" < "eggs"

By having that, we could throw away arglists as a matter of principle.
While I would suggest to still accept
        canvas.draw(path(...), linewidth(...))
It should automatically behave like
        canvas.draw(combine(path(...), linewidth(...))

That's it for the moment. I would feel very comfortable having a
combine like described above. The idea with the ``@'' is just nice,
but combine is quite nice too and does not leave the python language.

Any comments are appreciated.

Andr=E9

--=20
by  _ _      _   And...@Ph...
   / \ \    / )  http://www.physik.uni-augsburg.de/~wobsta/
  / _ \ \/\/ /   watch a movie and learn about the mystery tippe top:
 (_/ \_)_/\_/    http://www.physik.uni-augsburg.de/~wobsta/tippetop/