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

[Joerg L. <jo...@us...>]

On 26.02.02, Andre Wobst wrote:
> 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.
>=20
> 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).
>=20
> 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.)

True, very flexible and thus also somehow ugly...

> 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.

So the simple solution won't work here...

> 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:

This is exactly, what I meant with object oriented, i.e. a glue class.

> --  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")
>=20
>     --  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).

Ok, it starts to become complicated, maybe combineop can just be a
special case of combine. But I think, such things need a little more
considering.=20

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

Hmm, not absolutely necessary, if not in general ill defined...

> 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(...))

Maybe.

>=20
> 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.

True. But in my opinion the details of something like combine still
have to be worked out. We should not do things in a too complicated
way!=20

Hey, just to go over to something completely different. How about
dropping the unit in canvas, i.e. the late evaluation of units?
I'm becoming more and more in favour of it, since I don't like:

- passing a canvas for the intersection of bezier curves
- passing a canvas for tranforming a arct into a bezier curves

Both times, the canvas is absolutely necessary, so we are doing
something wrong. At the moment I'm thinking of a solution, where
you can only use uvw via a instance u("1 u mm"), which is the=20
instance of a class generated by a metaclass unit:

        u=3Dunit.unit(scale=3D{'u':1.5,...})

Ok, metaclasses, but it would be a perfect fit ;))

        J=F6rg