This naughty language of ours violates hallowed Structure Programming sophistries

[Phlip]

Rubies:

Please review for accuracy:

Before Object Oriented Programming, people who studied the difference
between cruft and maintainable code learned to improve things by linking
control flow to variable scope. An example in C:

if (whatever())
{
int x = something();
somethingElse(x);
}
x; /* this line won't compile, unless another x is available from
above */

Structured Programmers decry the mighty goto keyword, able to leap tall
procedures in a single bound. When a language permits a goto unfettered by
that language's block system, {}, variables defined in statements controlled
by goto have ambiguous scope. Structured Programming enables the style
guideline "give identifiers the most restricted scope possible".

I am unaware if Ruby supports goto. (Please please please don't tell me if
it does or not!) Object Oriented Programming subsumes all Structured
Programming ideals. However, Ruby permits this:

def newThing()

if something() then
element = constructor(TkcLine)
else
element = constructor(TkcPolygon)
end

element.configure('smooth', '1')

end

Ruby creates variables by assigning to them. That cures an ancient problem
with the C languages, where variables can define without values. The lowly C
statement int x; efficiently produces an x that might contain anything, and
should not be used until assigned. Ruby fixes that problem by forbidding
creation without assignment.

Ruby variables create into their method's scope, not their block's scope.
That's why the above code works - it tweaks the Structured Programming
rules. The element inside the if statement's blocks should, in theory, exit
scope and disappear before the last element.

Ruby supports Structure Programming much more subtly than by decrying goto.
When a goto leaps a tall procedure in a single bound, the root problem is
that tall procedure itself. Ruby's syntax maximizes opportunities to
minimize code. The style guideline "don't goto" is subservient to the
Simplicity Principle "Minimize Statements, Methods, and Classes".

For example:

def newThing()
klass = if something() then TkcLine else TkcPolygon end
element = constructor( klass )
element.configure('smooth', '1')
end

 

[Rando Christensen]

Before Object Oriented Programming, people who studied the difference

between cruft and maintainable code learned to improve things by linking
control flow to variable scope. An example in C:

if (whatever())
{
int x = something();
somethingElse(x);
}
x; /* this line won't compile, unless another x is available from
above */

I've always believed that the key principle behind coding with scope in
mind is not how the scope is implemented so much as understanding the
rules of variable scope for the language and using them to write solid
code that is not as prone to errors.

Remember, a bad programmer will write bad programs in any language, and a
good programmer will write good programs in any language (given sufficient
time to understand the language). Any rules that the language enforces,
whether for scoping or for language structure or whatever, do not alter
this.

 

[David A. Black]

Hi --

Rubies:

(I think of myself more as a Ruby*ist*, but so be it

Ruby variables create into their method's scope, not their block's scope.
That's why the above code works - it tweaks the Structured Programming
rules. The element inside the if statement's blocks should, in theory, exit
scope and disappear before the last element.

'if' doesn't create a new scope, but code blocks do:

$ ruby -e ' [1,2,3].each {|x| p x; y=1}; p x rescue puts $!;
p y rescue puts $!'
1
2
3
undefined local variable or method `x' for main:Object
undefined local variable or method `y' for main:Object

So the method/block scope distinction doesn't generally hold. (This
is among the areas under revision for 2.0... so stay tuned.)

The "in theory" bit is a little damning, since it suggests that Ruby's
design in this regard violates some general theory or principle, which
I don't think it does. Having 'if' be of flat scope is a different
*practice* than other languages, but I don't think there's any
theoretical mandate to do it one way or the other.


David

 

[Robert Klemme]

Ruby supports Structure Programming much more subtly than by decrying goto.
When a goto leaps a tall procedure in a single bound, the root problem is
that tall procedure itself. Ruby's syntax maximizes opportunities to
minimize code. The style guideline "don't goto" is subservient to the
Simplicity Principle "Minimize Statements, Methods, and Classes".

For example:

def newThing()
klass = if something() then TkcLine else TkcPolygon end
element = constructor( klass )
element.configure('smooth', '1')
end

I'm not sure what you want to show with this, but if you want to minimize
code there are other solutions:

def new_thing
thing = ( something() ? TkcLine : TkcPolygon ).new
thing.configure('smooth', '1')
thing
end

Note that your method relies on the implementation of #configure to yield
the proper return value. IMHO that's bad practice since this requires more
of #configure than necessary.

Regards

robert

 

[Phlip]

The "in theory" bit is a little damning, since it suggests that Ruby's
design in this regard violates some general theory or principle, which
I don't think it does. Having 'if' be of flat scope is a different
*practice* than other languages, but I don't think there's any
theoretical mandate to do it one way or the other.

Guys, everyone needs to look "sophistries" up in a dictionary.

 

[David A. Black]

Hi --

Guys, everyone needs to look "sophistries" up in a dictionary.

Take them or leave them, but my comments were made in full knowledge
of what that word means.


David

 

[Jamis Buck]

David A. Black wrote:




Guys, everyone needs to look "sophistries" up in a dictionary.

From m-w.com:

"Sophistry: (noun) subtly deceptive reasoning or argumentation"

Hmmm. I don't see how David's comment in any way fits that definition.
Could you be a little more explicit in your accusation? I personally
concur with David's statement.

- Jamis

--
Jamis Buck
(e-mail address removed)
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

 

[Phlip]

"Sophistry: (noun) subtly deceptive reasoning or argumentation"

Hmmm. I don't see how David's comment in any way fits that definition.
Could you be a little more explicit in your accusation? I personally
concur with David's statement.

I wrote the Subject line, not Dave.

 

[David A. Black]

I wrote the Subject line, not Dave.

Nor I


David