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

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

Hi,

On 25.02.02, Joerg Lehmann wrote:
> > I think, we do *not* mix arglist and argdicts here. And I'll add
> > another example in order to clearify my problems (show may be defined
> > as above):
> >=20
> > def showtitle(title =3D "some default", subtitle =3D "some default"):
> >     show(title, A("red"))
> >     show(subtitle)
> >=20
> > We can do now:
> >=20
> > showtitle("text")
> > showtitle(title =3D "text")
> > showtitle(title =3D "text1", subtitle =3D "text2")
> > showtitle(title =3D ("text1", A("blue")), subtitle =3D "text2")
>=20
> So you have to A("Blue") and A("red") for title, where the second one
> overrides the first one, which should presumably be the default?

Indeed.

> But the output corresponding to such a solution wouldn't be very
> nice, would it?

Yes, for that case it is bad. But the behavior is quite right, I
suppose. It is just a feature of that color change, that it destroys
everything about the previous color change, so that it doesn't make
sense to apply it twice. We should therefore just remove the color
change that wouldn't take effect because it is overwritten. This task
should be fullfilled by the show/draw (whatever) routine. In order to
be able to do this, it might use some information given within the
attributes, or ask the attributes themselfes and additional we can
make use of the class tree for doing so.

However, I would suggest not to implement that at the moment, because
it is not crucial at all. We should be sure, that it can be done and
that's it for the moment. Of course, you're welcome to already
implement this, but I think, it is not crucial in order to prepare
version 0.1.0.

BTW, there are cases, where it is usefull to apply the change twice,
although it is the same attribute. Immediately transformations come
into my mind. We discussed, that we should reserve that for an
subcanvas (which I still think is a good idea). But nevertheless,
because we're suppose to use an arglist there too, at that point we
must not throw away any transformation ...

> > Both, title and subtitle could have some attribute of class A. You
> > can't distinguish it without tighten this attribute to title itself.
> > (Please don't come up with some way getting this out of the ordering
> > of the arguments.) So title and subtitle themself are just argdict
> > arguments, but they *themself* are arglists. They can get parameters
> > exactly like the show routine itself. At the same time, showtitle can
> > easily provide default attributes to a title (like the color red in
> > the examle). To my eyes, this technique is very transparent for both
> > developers and users.
>=20
> 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.

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?

> > > Why don't we just use
> > >=20
> > >         self.title =3D dict.get("title", "")
> > >=20
> > > and don't ever specify the parameters explicitly in the function
> > > definition.
> >=20
> > You're right that this would be a solution. But do we really want to
> > give up the standard way of having default arguments? We could never
>=20
> Isn't this a standard way? I saw it many time before.

I've also seen that before. But I think it's a bad solution.

> > write define axis.__init__(self, min =3D None, max =3D None) anymore.
> > Instead, we would get a much less convenient way of writing
> > parameters. And another crutial thing. What happens if somebody
> > misspells title in his parameter list ... he would never get any
> > warning about writing tilte ... the value of the parameter would just
> > be ignored.
>=20
> Concerning your last point: this could be avoided if we track the use=20
> of all parameter names. If there is eventually some parameter left, we
> could throw an exception...
> But I still think, that such a solution could be automated very well,
> and therefore it would be possible.

Do you mean to create a kind of meta-class providing this. Or would
you suggest to always have to call that kind of methods. I encourage
your idea. It would also help out of the multiple inheritance problem
(which is indeed a huge disadvantage from a design point of view). But
I was trying to make the point, that we could try not to go along that
line.


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/