[Baypiggies] Frequently Argued Objections

[Shannon -jj Behrens]

Your post did bring up one thing I do like about Ruby.  It has a more
defined notion of class scope at class definition time.  If Python had
that, I could do something like:

class B(A):
    ...
    if hasattr(B, 'foo'):
        ...

That's not possible now, because B doesn't exist until the class is
finished being defined.  There are workarounds.  It's not a big deal.
I'm just saying ;)

-jj

On Mon, Jun 23, 2008 at 4:35 PM, Warren Stringer <warren at muse.com> wrote:
> Ok, so "var=x" instantiates a static var x, yes? For example:
> class a(object):
>     b=1
>     # self.b does not work here
>     def __init__(self):
>         self.b=2 # so declare it in the constructor
>     def f(self):
>         b=3
>         print a.b, self.b, b
>         b=b+1
> i=a()
> i.f() # => prints 1 2 3
> a.b=4
> i.f() # => prints 4 2 3
> j=a()
> j.f() # => prints 4 2 3
> a.b=5 # will change for i and j
> i.f() # => prints 5 2 3
> j.f() # => prints 5 2 3
> i.b=6 #changes self.b
> i.f() # => prints 5 6 3
> j.f() # = prints 2 6 3
>
>
>
> So, the ambiguity is that
>
>     whatever=a() will instantiate b=1 once, whereas
>
>     whatever.f() will instantiate b=3 always
>
>
> Must keep track that
>     a.b behaves differently from i.b, since
>     i.b=6 implicitly passes self,
>         somewhat akin to i.self.b, tho not quite
>          (how would one express as internal dictionaries?)
> As stated about @var, in Ruby:  "but conceptually bends Occam's razor -- it
> makes the language introduce one more rule"
> One may make the case that examples for b=1, b=3, a.b=5, i.b=6 also
> introduce more rules.
> This is what confused me the most, when learning Python. I have heard
> similar objections. I have seen plenty of questions posted about this
> problem and have seen many replies posted that essentially say "oh no, not
> THAT question again."
> There are several methods of dealing with objections:
> 1) ignore it by calling it whining
> a) and hope the whiners go away
> 2) acknowledge the problem
> a) show how it solves a bigger problem
> b) show how a fix would create new problems
> 3) eliminate the source of the problem
> a) without creating new problems
>
> Guess which methods increase the popularity/longevity of a product? Since 3)
> is not going to happen for self, I would suggest 2) over 1).
> \~/
> On Jun 23, 2008, at 8:40 AM, Alex Martelli wrote:
>
> On Mon, Jun 23, 2008 at 7:41 AM, Warren Stringer <warren at muse.com> wrote:
>   ...
>
> My guess is that:
>
>       1)  9 times out of 10 the var in self.var is blindingly obvious,
>
>       2) 99 times out of 100 it is obvious after a 10 second search,
>
> I think that there are way more than 1 in 100 uses even just for the
> simplest example that shows this guess to be unfounded: "self.var = x"
> which would allowed to become "var = x"  under a deleterious "implicit
> self" rule.
>
> Right now, "var = x" sets a local variable in the method, "self.var =
> x" sets an instance variable: zero ambiguity, zero chances for error,
> zero problems -- well let's say epsilon problems rather than zero,
> because there IS the issue of having to listen to whines against
> "mandatory explicit self";-).
>
> There are good ways and bad ways to address this issue during language
> design. The best way -- as in Modula-3, Python, Perl-5, Ruby -- is to
> explicitly mark instance variables (self.var in Modula-3 and Python,
> $self->{var} in Perl-5, @self in Ruby); a somewhat inferior way -- as
> in Squeak -- is to give up some of the language's dynamic nature by
> forcing variables to be declared; a worse way would be to break
> symmetry by using the explicit mark in assignment but not in
> reference.
>
> The very worst way is shown by Javascript's "with" statement -- within
> a Javascript "with zap", the meaning of "zop = 23" is essentially
> unguessable as it depends on whether zap already did have a zop
> attribute (in which case it rebinds it) or not (in which case it binds
> a global variable -- unless there was an earlier declaration of "var
> zop" in this function, in which case it binds the local variable
> instead) -- a mix of forced declaration and blind guessing that good
> books on Javascript (e.g. the short and useful "Javascript, the good
> parts") strive to convince the reader to never, ever use that accursed
> statement.
>
> Within the "explicit mark" camp, Ruby's "@var" is typographically
> concise but conceptually bends Occam's razor -- it makes the language
> introduce one more rule (on the meaning of a "@" prefix) where the
> choice that Python took from Modula-3 just reuses an existing rule
> (whatever.var means exactly the same in all cases, whether "whatever"
> is "self" or something other than "self" -- no special cases, no extra
> rules).
>
>
> Alex
>
>
>



-- 
It's a walled garden, but the flowers sure are lovely!
http://jjinux.blogspot.com/