Re: [Edu-sig] Uniform Access Principle confusion
-----Original Message----- From: Kirby Urner [mailto:urnerk@qwest.net] Sent: Wednesday, October 12, 2005 2:25 PM To: 'Arthur'; edu-sig@python.org Subject: RE: [Edu-sig] Uniform Access Principle confusion
Note that passing an argument is not the only way to tell an object stuff like "my preferred unit of measure." That could also be regarded as a change in state, and be handled with another attribute, e.g.:
Triangle.anglemeasure = 'degrees' # set default class attribute mytri = Triangle((30,60,90)) # instantiate using degrees
But in my (perhaps overly strict) way of OO thinking the unit of measure is an attribute of the angle, not of the Triangle. Is there a way to a accomplish a "change of state" of the angle "attribute", other by sending it a parameter? Art
But in my (perhaps overly strict) way of OO thinking the unit of measure is an attribute of the angle, not of the Triangle.
I think of the unit of measure more as an attribute of the viewer, so if this were MVC-style OO, we'd probably keep the model in some internal unit, perhaps integer, while translating to time/size units (e.g. ergs) per some request into the model by a view, as mediated by the controller. For example, with the Triangle class, we might just define __slots__ for 3 xyz tuples (per your point re __slots__, yes, for economy in memory) -- and that's it. A viewer class might glom on and suck down a reference to a triangle object, and from self's three slots spit back all angle and edge measures, in whatever language or units. A French Imperial bot could spit back in French.
Is there a way to a accomplish a "change of state" of the angle "attribute", other by sending it a parameter?
Art
Well, you could do as follows:
mytri = Triangle() mytri.C.degrees 90 mytri.C.radians 1.5707963267948966
In this case, the angles are thought of as "sub objects" each with their own sets of attributes, in this case both radian and angle measure. The subobjects might also support actions, e.g. mytri.C.break() or mytri.C.colorize('Red') -- note verbs. Just mytri.Cd and mytri.Cr would likely be less confusing (degrees and radians respectively -- we maybe don't know if these are implemented as properties unless we have access to the source code). Note that many programmers visualize a GUI on an object, when coding with it, i.e. they'll translate the published API, all spelled out in formal syntax, in terms of slider bars, popup menus, other widgets (it's like the cockpit of an airplane, once the objects get complicated and plentiful enough). That's like a customized "programmer specific" view *into* a model. The model itself contains to views. I saw some examples of this the other night at PORPIG. Dylan projected some Zope 3 off his Linux laptop, showing a simple 'hello world' object being defined in terms of MVC. A .py file defines M. V is handled by interfaces (links to another template XML: .zcml). These go in product subdirectories. C (the Controller) is Zope itself in this case i.e. py classes + interfaces + Zope = MVC. Kirby
model. The model itself contains to views.
That should have been: "The model itself contains NO views." I was doing MVC earlier a bit on this list: http://mail.python.org/pipermail/edu-sig/2005-August/005087.html To see where our discussion of the Triangle class begins check: http://mail.python.org/pipermail/edu-sig/2005-August/005057.html (this later became a discussion of the Python properties feature, plus decorators). For a good example of a Zope 3 project check out SchoolTool: http://www.schooltool.org/ Kirby
participants (2)
-
Arthur -
Kirby Urner