[Edu-sig] Uniform Access Principle confusion

[Arthur]

> Behalf Of Arthur
> 
> But I am certainly convinced that the freedom to make mistakes is
> unassailable as part of a learning process. And therefore conclude that
> programming in the style that Python allows is an unassailable and
> under-utilized educational resource.

Clarifying what I mean here, and asking some real questions at the same
time.

No, I don't think writing code in Python is so free as to be more subject to
the problems of programmer error, but that's OK because it is good for
learning.

What I do mean perhaps goes back to the discussion of properties and the
Uniform Access Principle.

There are languages that believe so strongly in the importance of the UAP,
that it is imposed within the design of the language - from what I see Ruby
and Eiffel offering the strictest implementations.

But if one were to be learning programming from, say Ruby, it seems to me
that there are at least two things that it will be near impossible to
discover:

1) The basis for a conclusion that the Uniform Access Principle should be
considered an inviolate principle.
2) The basis for a conclusion that it should not be.

Because one cannot explore the possibilities (and problems) of working both
within and outside of it.

The Python environment - providing properties as a convenience for exploring
the possibilities of working within it, and the ability to ignore them for
exploring the possibilities of working without - seems optimum. For
learners/explorers - for sure. But I would expect for fully grown-up
programmers as all.  

That being said - still not getting the UAP thing.

Which seems to be saying that distinguishing between assigned attributes and
methods that do not take parameters is an implementation detail, and hiding
it, benefits (is essential to) API design flexibility - via a decoupling.

But why is distinguishing between methods that do and do not take parameters
any more justified, and isn't doing so its own kind of violation of a
principle of decoupling.

None of this questioning coming from the abstract realm  - because I am
exploring in a language that does inhibit exploration.

If anyone is still reading...

One of the cases in which I used properties and thought I had it right - on
the getting of a vector I wanted the return, for purposed of drawing, to be
constrained to some MAX value, which is a module level constant.  So I had a
method that would return a constrained vector, and since the vector itself
was a plain attribute, it felt right to flatten this constrained version of
a vector via a property.

Now I find there are advantages to having the MAX value be sensitive to
certain conditions of the caller.  And I want the caller to call the method
with a MAX value that is appropriate to its needs.  So I have no choice but
to de-propertize the method.

In the case of Kirby's Triangle angle, might it be wise to avoid the
possibility of exploding any spacecraft, and insist that a contract be
formed with the caller so that the caller must specify whether they are
expecting the return value in radians or degrees?  Seems maybe yes.  But
that requires a parameter, though changes nothing else about what the angle
is in relation to the Triangle. 

So the UAP is not getting through here.

Art