In a message of Fri, 26 Aug 2005 18:24:33 EDT, Arthur writes:
And am hoping he is quite wrong in the assessment that information hiding
is a base requirement for information science. ;)
He is quite correct, but 'hiddenness' is not an infinite human good,
such as health. It is quite possible to
-Original Message-
From: Laura Creighton [mailto:[EMAIL PROTECTED]
One nice thing about overwriting __getattr__ and __setattr__ is
that when you are done you have something that fairly shrieks
'black magic here'. Properties look innocuous. Some people go quite
nuts with them,
-Original Message-
From: Laura Creighton [mailto:[EMAIL PROTECTED]
My guess is that you think that properties violate 'Explicit is better
than implicit.'
Not exactly.
More like I think that it encourages theory, and I appreciate Python as
a-a-theoretical.
The counter argument is
Separating these matters in an educational setting is more than
problematic.
Art
In an educational setting, I use analogies.
Think of interacting with a waiter in a restaurant. Your expectation is you
name the foods and drinks you want, and after a period of time, those items
arrive at
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
Information hiding means sparing me the details. In an open source
world,
I might be able to see those details if I really cared about them. In the
case of a private bank, fat chance.
Yes, we are at the core of
In my MVC example, the Viewer expected a 'shape' object to support a
specific API: verts and edges needed to be available as attributes.
Let me try to practice better what I think I am preaching and follow your
lead in making the discussion more concrete and less theoretical.
I have a line
Arthur wrote:
I have a line segment - defined as the segment connecting 2 points. The
interface allows the points to be picked and moved.
The line segment has a length. I choose line.getLength() as my API
Am I - in fact - violating the Uniform Access Principal.
If I am, am I
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Scott David Daniels
My strongest reaction has
to do with your wish to deny me the ability to make another choice
If that is a reference to my opinion about the visibility of the built-in
property
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Scott David Daniels
If I am not violating the Uniform Access Principal how do we express on
what
basis I am not?
This to me has to do with the set of calls in your API.
Yes but according to
Kirby Urner wrote:
So I find that rejecting it as naïve is fundamentally unresponsive.
Art
However in this case I don't think your views were rejected as naïve. On
the contrary, your views permeated a sophisticated discussion of use cases,
and design patterns more generally (s'been a rich
Kirby seems comfortable in the Meyerist camp.
I think you might be reading something too sinister into information
hiding and are therefore against it.
The brutal real world truth is the client wants an API that works today, but
will complain if it doesn't deliver tomorrow, even if specs
I think use cases were described, and demonstrated, in which the property
feature made sense, e.g. we wanted an attributes-based API into our
triangle object, but sometimes the results were computed on the fly.
And I notice that without the use of properties, that which is computed on
the
-Original Message-
From: Arthur [mailto:[EMAIL PROTECTED]
So I find that rejecting it as naïve is fundamentally unresponsive.
Just to add -
I would feel my approach - no question - more misplaced most other places.
But think Guido's ability to retain a sense of naivety in the
So I find that rejecting it as naïve is fundamentally unresponsive.
Art
However in this case I don't think your views were rejected as naïve. On
the contrary, your views permeated a sophisticated discussion of use cases,
and design patterns more generally (s'been a rich thread) plus Scott
Disclaimer: I haven't followed this thread as closely as I should.
Picking up on a few words from the discussion
(namely triangle and properties).
When I think of a real life triangle, I can describe it
in terms of various properties, such as: the length of
each of its three sides, its area, the
Hi Andre --
If you scroll back, you'll see I was specifying a triangle object in which
sides a,b,c were passed to a constructor, *and* could be respecified on the
fly, thereby changing the triangle. A validator made sure the proposed
triangle was legal (triangle inequality not violated). Other
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
I *enjoy* your exotic other-worldliness.
Other than what, I'm wondering ;)
Art
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
I guess.
Though I can't say I find there to be much consensus out there about what
language features truly make for robust software development from group
or community efforts.
There's a long history of coders seeking consensus, but not arriving at any
set in stone answers (no carved
Chuck Allison wrote:
Since this discussion has swerved a little, I'd like to pose a query.
I've been using patterns since 1995 and am teaching a course starting
Wednesday (a full semester course) on Design Patterns using the Heads
First book. My query: do you have any ideas you might proffer
- Original Message -
From: Scott David Daniels [EMAIL PROTECTED]
If I wait until I have actual users, I can get
real statistics on how the use the API. We decouple our work this
way.
But in my look of it, properties are a solution to one of a nearly infinite
set
of these kinds
-Original Message-
From: Chuck Allison [mailto:[EMAIL PROTECTED]
Sent: Monday, August 22, 2005 12:43 PM
To: Kirby Urner
Cc: 'Arthur'; 'Scott David Daniels'; edu-sig@python.org
Subject: Re[2]: [Edu-sig] Design patterns
Hello Kirby,
Since this discussion has swerved a little
In his mind, (and I think in yours as well) computer languages are more
like mathematical notation than a form of technology. And as such,
evolution is slower - not at the pace of the changes in the underlying
technology.
However I'm sometimes in the mood to not draw this line between
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
They're not here to whine about not being mere math notations as if that
would be an improvement.
That's one way to attempt to characterize my point - or Graham's point, for
that matter.
Except that it of course
Subject: Re[2]: [Edu-sig] Design patterns
Hello Kirby,
Since this discussion has swerved a little, I'd like to pose a query.
I've been using patterns since 1995 and am teaching a course starting
Wednesday (a full semester course) on Design Patterns using the Heads
First book. My query: do you
Arthur wrote:
... more to my point is the fact that I don't expect my programming language
to solve the problem of decoupling my API from my code. Because I don't
expect it to be a solvable problem.
I don't know if I'm beating a dead horse, but I don't claim properties
solves the problem of
Chuck Allison wrote:
My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html.
One thing I've always wanted to see if the class is small enough:
Groups shuffling other group's previous layers, and providing
feedback (but not grades) to the original group. It is
always
I guess.
Though I can't say I find there to be much consensus out there about what
language features truly make for robust software development from group or
community efforts.
There's a long history of coders seeking consensus, but not arriving at any
set in stone answers (no carved
Hello Kirby,
Since this discussion has swerved a little, I'd like to pose a query.
I've been using patterns since 1995 and am teaching a course starting
Wednesday (a full semester course) on Design Patterns using the Heads
First book. My query: do you have any ideas you might proffer for
Arthur wrote:
What beyond sugar for leaving off a () when trying to retrieve a value
from a method are we accomplishing by using properties? I have tended to
look at properties mostly an accommodation to those coming from other
languages which have something similar, but never as something that
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
A weakness in the above design: we only check for violations of triangle
inequality in the constructor, yet allow changes to a,b,c through the API.
Among my list of unsupportable theories is one to the effect that any
PyGeo has a Triangle object, inherited from the Plane object. It exists
mostly for drawing purposes, as the portion of the plane enclosed by the
infinite lines connecting any 3 points. Since all Triangles are
projectively equivalent, in the context of PyGeo there is little to be
gained by
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
Good point about all triangles being equivalent given projection. In
nailing down the angles, we've inadvertently defined a fourth vertex: the
point of view. Given we're talking four vertices, we should maybe rename
Arthur wrote:
As an API matter, I find myself liking the clue that () provides as to
whether one is accessing something designed be determined dynamically.
In general I agree with that sentiment.
I find myself leaning towards the option of making the use of properties go
away in PyGeo.
Though when we add another dimension, all tetras are projectively
equivalent. Part of why I can't adjust to a focus on a tetra that happens
to be regular in some way.
Art
Well, another way of putting it is: all tetrahedra are the same regular
one, except not because of viewpoints.
Kirby
-Original Message-
From: Kirby Urner [mailto:[EMAIL PROTECTED]
A lot of these lessons about robust software development come from group
or
community efforts. Some aspects of Python maybe don't much excite you
because you're primarily a solo coder (as am I much of the time).
I
I’ve been thinking that a good way to introduce program design might involve
objects of type Triangle, i.e. instances of the Triangle class.
mytri = Triangle(3,4,5)
mytri.area
6.0
mytri.C
90.0
Now isn’t it true that 3 sides uniquely determine a triangle *except* some
triangles have
36 matches
Mail list logo
