On Tue, 18 Sep 2007 18:02:59 -0400, Lew wrote:
You can’t do both in Java. Is a an array or a String? If a is a String
and b is an array, then neither a = b' nor
b = a’ will compile in
Java.
Java is a strongly-typed, compiled language which means it does more
static type checking and thus would reject treating a as both an array
and a String.
In that environment the programmer must choose one or the other.
In this Java example, a and b are statically typed to be of type Object.
Both Strings and Arrays descend from Object. (And primatives like
integers and the like will be autoboxed into descendants of Object).
Hi
Radiant is not active or has very slow development cycle . furthermore
I dont think radiant has cutting cutting edge .
A RoR based cms can have fast development cycle with many features in
it
Radiant is very good and powerful cms system but We need more than that
that’s why we started the Great Ruby cms (TGRCMS).
Thanks
Roel Schroeven wrote:
Lew schreef:
Nah, this dude’s all right, so far. As if my opinion mattered.
Stay with it, Summercool. It’s what discussion groups are for.
Here’s why the reaction: cross-posting of computer-science-type essays,
something Xah Lee does. But he recycles all his decades-old crap and really
doesn’t participate in the discussion. This isn’t that at all.
I fully agree and I didn’t in any way mean to compare Summercool to Xah
Lee. My apologies to Summercool if anyone interpreted it that way.
Since Summercoool is most likely Xah Lee, the comparison is fair. The
post has been spammed to all the news groups–as usual.
On Sep 18, 2007, at 11:46 PM, Rick DeNatale wrote:
The only thing special about Ruby’s ‘primitive’ classes is that they
behave such that identity is isomorphic to equality. That is to
say that a.equal?(b) if and only iff (a == b).
Actually that’s not really special, it’s true of any object which
hasn’t overriden Object#==
Perhaps ‘special’ was not the right term. I didn’t mean to
suggest that the behavior was unique to those classes just that
they had that particular property.
Gary W.
Lew wrote:
Java is a strongly-typed, compiled language which means it does more
static type checking and thus would reject treating a as both an array
and a String.
In that environment the programmer must choose one or the other.
Ken B. wrote:
In this Java example, a and b are statically typed to be of type Object.
Both Strings and Arrays [sic] descend from Object. (And primatives [sic] like
integers and the like will be autoboxed into descendants of Object).
That doesn’t make Strings and arrays assignment compatible, and besides,
it
isn’t so.
It was not stated by the OP that they were statically typing the
variable to
Object. In fact, their example used a type “Animal”. They also used
the
syntax “a[1]”, which is not possible in Java with a variable of type
Object.
So clearly a and b are /not/ statically typed to Object.
Unless you meant “/if/ a and b are statically typed [to] Object” that
the
assignment will work, which is true but of sharply limited usefulness.
In that case, you are a) defeating Java’s type system and b) not getting
the
benefit of the Stringness or arrayness of the variable. This is in
contrast
to the dynamically-typed languages wherein the variable will behave like
an
object of the runtime type, unlike in Java.
Back to the OP’s example:
Summercool wrote:
so that’s why a[1] = “foobar” will change what b will display, but
a = “foobar” will not change what b will display.
Again, this cannot be done in Java. The same variable a cannot be set
to a
String and still be used with array syntax.
Russell Wallace wrote:
Is that the case: if a is an object, then b = a is only copying the
reference?
Yes, your understanding is exactly correct; C++ will assign by value
unless you explicitly use pointers, but the other languages will assign
by reference (except for primitive types).
Ada also assigns by value absent explicit use of access variables
(similar to pointers or references).
The question, in fact, is meaningless. Java has a certain defined
behavior. C++ has a certain defined behavior. Smalltalk has a certain
defined behavior. LISP has a certain defined behavior. Ada has a certain
defined behavior. Object-oriented languages as a class do not.
Radiant is not active or has very slow development cycle .
furthermore
I dont think radiant has cutting cutting edge
John, Daniel, and Sean are very active on the Radiant list, and a
significant new functionality was added to trunk this week. So I’m
not sure where you got the notion that it wasn’t active.
A RoR based cms can have fast development cycle with many
features in
it
Radiant runs on rails
Radiant is very good and powerful cms system but We need more than
that
that’s why we started the Great Ruby cms (TGRCMS).
Which comes back to the original question, what exactly are you going
to be doing differently? At the moment the only suggestion seems to
be more active development, which in reality is difficult to sustain
over an extended period. If that is the only point of difference,
then personally I think efforts would be better spent improving and
adding to one of the existing solutions out there rather than re-
inventing the same thing all over again.
Regards,
Glenn
On 9/20/07, Todd B. [email protected] wrote:
100% agree.
I feel I should add, also, that another big stumbling block for people
new to the language is how scope is handled. It’s made pretty clear
in the pickaxe, but is oftentimes lost to the new developer while they
sit in front of the screen.
Todd
On 9/18/07, Rick DeNatale [email protected] wrote:
As a long-time observer and contributor to this forum, I’ve got to say
that this subtle distinction between variables and objects has tripped
up more than it’s fair share of newbies. It might well be the #1
stumbling block for many ruby learners. Not to mention other similar
languages.
+1
100% agree.
Todd
Jim Langston wrote:
};
[…]
none of which the default assignment operator would of done.
[…]
Incidently, there may be errors in the code I’ve shown here if you attempt
to compile it. Be forewarned.
There’s the “self-assignment” bug. See the popular C++ FAQ.
Follow-ups to comp.lang.c++