[Pythoncard-users] FW: dot notation revisited

[Kevin A. <al...@se...>]

I sent this to the anygui to see if the Python gurus over there had a
reasonable solution. I think that what we will probably end up having to do
if we keep dot notation is provide wrapper classes whenever an 'attribute'
is a mutable complex type such as 'font' which is a class and 'items' which
is a list. Most of the other attributes are immutable (strings, tuples) or
simple types (integer) so they aren't a problem.

Wrapping 'items' (a subclass of UserList) or enhancing the Font class is
going to be unclean and isn't going to be any fun and I don't know how it
will impact our ability to eventually support plug-ins say via XPCOM.

One scenario is that we abandon dot notation in which case we'll be back to
normal get/set methods, which is uglier and more to type, but at least it is
consistent and won't surprise anyone by not working the way they expect.

This is probably one of the biggest syntax issues we have to decide. If you
have strong opinions one way or another, you should speak up.

ka

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Tuesday, August 28, 2001 8:47 AM
To: any...@li...
Subject: dot notation revisited


I've run into yet another dot notation issue with PythonCard. I'm bringing
it up here, because it looks like you're heading down the same road, so
maybe you already have a solution.

The problem is when the _get/_set for an attribute involves a complex
mutable type. This could be a list, a dictionary, or another class. I first
ran into it with setting the font for a widget. For example, this is what a
user might like to do:

  self.components.field1.font.size = 12

However, because 'font' is actually a virtual attribute represented in
reality by a _getFont and _setFont what you have to do is:

  f = self.components.field1.font
  f.size = 12
  self.components.field1.font = f

If there was __getattr__ and __setattr__ magic then the user would use (I
removed the leading underscore):

  f = self.components.field1.getFont()
  f.size = 12
  self.components.field1.setFont(f)

so the user in the first instance is effectively trying to do:

  self.components.field1.getFont().size = 12

or at least I think that is what is going on.

Further nastiness occurs with Choice (popup menu), List (scrolling list),
and RadioGroup (group of radio buttons) where there is an 'items' attribute
which is basically a Python list, so to get or set the entire list in one of
the controls you have something like:

  aList = self.components.chsTable.list
  self.components.chsTable.list = aList

The problem occurs when someone tries something like

  self.components.chsTable.insert(0, 'hello')

That doesn't work. The solution would appear to be providing a wrapper class
using UserList and then implementing every list method which in turn does
the right thing to the underlying GUI control. This is a lot of overhead and
a lot of work. It appears that that kind of trickery needs to be done for
any attribute that is mutable and complex, so it isn't a problem with
strings, integers, floats, etc. but lists and dictionaries and classes are a
problem.

Does this make sense? How are you dealing with this in anygui or are you not
using dot notation for attributes?

ka