A little assistance please :)

So I’m still quite new to Ruby and so far I love it’s simplicity, but I
just can’t figure out why I’m getting this error?.. I know its probably
something I did thats very simple because at the moment, I just woke up
so I’m still kind of “waking up”…

So here is my current code:

And here is my error:

H:/RoboSteve/lib/RoboEngine.rb:17: syntax error, unexpected ‘\n’,
expecting tCOLON2 or ‘[’ or ‘.’
H:/RoboSteve/lib/RoboEngine.rb:28: syntax error, unexpected keyword_end,
expecting $end

Could anyone help me with this? Or tell me something I could to better
with my code?
(if you do so please explain why it’s better than what I’ve already got.
Please hold the rude comments to yourself.)

-Thanks

On 24 January 2012 17:14, Paet Worlds II [email protected] wrote:

So I’m still quite new to Ruby and so far I love it’s simplicity, but I
just can’t figure out why I’m getting this error?.. I know its probably
something I did thats very simple because at the moment, I just woke up
so I’m still kind of “waking up”…

Then perhaps you should have waited for your morning coffee to kick in?
:slight_smile:

So here is my current code:
RoboSteve (V3) - Pastebin.com

And here is my error:

H:/RoboSteve/lib/RoboEngine.rb:17: syntax error, unexpected ‘\n’,
expecting tCOLON2 or ‘[’ or ‘.’
H:/RoboSteve/lib/RoboEngine.rb:28: syntax error, unexpected keyword_end,
expecting $end

The problem is the “self.” in the class names.

Could anyone help me with this? Or tell me something I could to better
with my code?
(if you do so please explain why it’s better than what I’ve already got.
Please hold the rude comments to yourself.)

This last line actually made me wonder whether I should even bother
replying. You just assume we are going to be sending you “rude
comments”? Not very nice.

Hilco Wijbenga wrote in post #1042399:

On 24 January 2012 17:14, Paet Worlds II [email protected] wrote:

So I’m still quite new to Ruby and so far I love it’s simplicity, but I
just can’t figure out why I’m getting this error?.. I know its probably
something I did thats very simple because at the moment, I just woke up
so I’m still kind of “waking up”…

Then perhaps you should have waited for your morning coffee to kick in?
:slight_smile:

I couldn’t possibly hault my progress for coffee…

So here is my current code:
RoboSteve (V3) - Pastebin.com

And here is my error:

H:/RoboSteve/lib/RoboEngine.rb:17: syntax error, unexpected ‘\n’,
expecting tCOLON2 or ‘[’ or ‘.’
H:/RoboSteve/lib/RoboEngine.rb:28: syntax error, unexpected keyword_end,
expecting $end

The problem is the “self.” in the class names.

What exactly is wrong with the self. ?o,o

Could anyone help me with this? Or tell me something I could to better
with my code?
(if you do so please explain why it’s better than what I’ve already got.
Please hold the rude comments to yourself.)

This last line actually made me wonder whether I should even bother
replying. You just assume we are going to be sending you “rude
comments”? Not very nice.

Please don’t take that personally… I haven’t gotten used to the use of
these forums just yet. I’m too used getting “trolled” for being new to
things >.< Sorry.

hi Paet,

welcome to ruby!

so, there are a few things with your code that are a little ‘strange.’

first - i’m not sure about defining classes as:

class self.WhatTheHeck
  ##
end

i think that’s where you /n (or newline) error is coming from, and i’m
not sure that this works at all - ditch the 'self’s.

second, remember that methods reside within the class you create them
in - so in line 25 when you call thoughtp.testforaccess from within
the Startup class, Startup has no idea what thoughttp is, nor what the
method testforaccess is.

also, in line 40, you define a method called Steveloaded - classes,
modules, and constants start with capital letters, not methods - this
will throw an error for sure.

i think that maybe what you’re trying to do is to instantiate one
class from within another, and then call some methods on the instance of
the first class from within the other. that’s no sweat… take a look
at something simple like this:

class Bicycle
def initialize
p “#{self} - i’m a 3 speed bike”
@gear = 1
end

def change_gear
p “#{self} was in gear #{@gear}”
@gear +=1
@gear = 1 if @gear > 3
p “and now #{self} is in gear #{@gear}”
end
end

class Automobile
def initialize
p “#{self} - i’m an automobile”
@speed = 55
end

def accelerate
p “#{self} was going at #{@speed} mph”
@speed += 15
p “and now #{self} is going at #{@speed} mph”
end
end

class ThingsWithWheels
def initialize
p “these are things with wheels…”
bike = Bicycle.new
car = Automobile.new
sleep(1.5)
bike.change_gear
sleep(1.5)
car.accelerate
end
end

rolling_stuff = ThingsWithWheels.new

is that something more like what you were after? notice too that i
use instance variables (variables that start with @) instead of global
variables (which start with $.) global variables are generally a bad
idea - they tend to muck up the works sometimes. instance variables can
be accessed from any method of a particular instance of a class, and
generally do the job quite well.

hth, keep at it!

  • j

On Tue, Jan 24, 2012 at 23:32, Chad P. [email protected] wrote:

Because self already has meaning in Ruby, when you try to define a class
like this:

class self.Startup

. . . Ruby is trying to call a Startup method on the Object object (no,
that repetition wasn’t accidental – there’s an object called Object) and
use the return value of that method as the name of the class you’re
trying to define.

So if I had a class with a method that returned a string, I could use
that where the name is expected in a class declaration? That doesn’t
seem right. Tried it in irb, using both a class method (Foo.bar) and
an instance method (foo.bar), and neither worked.

-Dave

On Wed, Jan 25, 2012 at 10:41:10AM +0900, Paet Worlds II wrote:

Hilco Wijbenga wrote in post #1042399:

The problem is the “self.” in the class names.

What exactly is wrong with the self. ?o,o

The “self” is a way to refer to the current object context. For
instance, in an irb session:

$ irb
>> self.class
=> Object

Because self already has meaning in Ruby, when you try to define a class
like this:

class self.Startup

. . . Ruby is trying to call a Startup method on the Object object (no,
that repetition wasn’t accidental – there’s an object called Object)
and
use the return value of that method as the name of the class you’re
trying to define. Of course, the return value of it is nil, because
there is no Startup method for the Object object, so to the interpreter
it looks like you’re doing this:

class

Because it’s difficult to see there, I’ll explain that there’s a space
after “class” followed by a newline, which is why Ruby is complaining
that there’s an unexpected “\n” (the escape character for a newline).
Ruby expects a class name to follow the “class” keyword.

That’s what’s wrong with the “self.” there.

On Thu, Jan 26, 2012 at 03:43:59AM +0900, Dave A. wrote:

On Wed, Jan 25, 2012 at 22:35, Chad P. [email protected] wrote:

No, you couldn’t do that either. I’m explaining why you got the error
Ruby gave you,

Just to clarify, I wasn’t the OP who got the error, I was just
interested in an odd implication of your explanation.

 end

end
EOF

eval(foo)

And to point out just HOW horrible that approach is, even aside from
the evil of eval… you have to remember to jump through additional
hoops and escape the #{@name}. Otherwise, it gets evaluated at
here-doc-parse time, as empty. That means hello.greet will just
return “Hello, !” (even if you did supply a name). If you escape it,
HelloWorld.new.greet properly returns “Hello, World!”, and
HelloWorld.new(‘Dave’).greet properly returns “Hello, Dave!”.

Now imagine layering another level of escaping on top of it, like if
you were doing things in the class, that in turn required the actual
final code to have some escaping. Bleagh.

There may be easier ways to achieve the same end but, in general, don’t
do it. It’ll probably just get your code in trouble.

Amen. Metaprogramming is very powerful… but with great power etc.

-Dave

On Wed, Jan 25, 2012 at 9:35 PM, Chad P. [email protected] wrote:

that repetition wasn’t accidental – there’s an object called Object)
Ruby gave you, not giving you suggestions for how to name classes in

There may be easier ways to achieve the same end but, in general, don’t
do it. It’ll probably just get your code in trouble.


Chad P. [ original content licensed OWL: http://owl.apotheon.org ]

It’s incredibly rare to need to resort to string evaluation. This
example
can be rewritten as:

bar = “Hello” + “World”

klass = Class.new do
def initialize(name=‘World’)
@name = name
end

def greet
return “Hello, #{@name}”
end
end

Object.const_set bar, klass

On Fri, Jan 27, 2012 at 05:18:53AM +0900, Dave A. wrote:

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

Test cases in a dsl test language like MiniTest/Spec or RSpec

describe “Foo” do
end
#=> Class FooTest < MiniTest::TestCase

On Fri, Jan 27, 2012 at 12:20:08PM +0900, Josh C. wrote:

def greet
return “Hello, #{@name}”
end
end

Object.const_set bar, klass

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

On Jan 27, 2012, at 10:43 , Chad P. wrote:

Why is that better than storing unnamed classes in a hash with keys for
the “names” instead of actually, dynamically assigning names to new
hashes?

Your question makes no sense as worded. I can't even guess at the intent.

P.S. I tried to do the above in yaml and it just didn’t feel as funny.
Close tags make things funnier.

On Fri, Jan 27, 2012 at 06:31:38PM +0900, Gunther D. wrote:

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

Test cases in a dsl test language like MiniTest/Spec or RSpec

describe “Foo” do
end
#=> Class FooTest < MiniTest::TestCase

Why is that better than storing unnamed classes in a hash with keys for
the “names” instead of actually, dynamically assigning names to new
hashes?

On Jan 27, 2012, at 01:31 , Gunther D. wrote:

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

Test cases in a dsl test language like MiniTest/Spec or RSpec

describe “Foo” do
end
#=> Class FooTest < MiniTest::TestCase

Not (currently) strictly true. describe does make a new class and
gives it a “name” but it doesn’t actually bother to set_const on
anything. It used to, way back in the day, but I gave it up because I
couldn’t decide what to do given A::C vs B::C and I didn’t want anything
breaking because of it.

That’s not to say that dynamically creating named classes is a bad
thing, just that it didn’t fit in this case given the inherent
complexities of tests.

jake kaiden wrote in post #1042402:

also, in line 40, you define a method called Steveloaded - classes,
modules, and constants start with capital letters, not methods - this
will throw an error for sure.

Actually, methods can start with a capital letter, and although it’s
not all that common, there are plenty of examples in the standard
library.

Integer(“123”)
=> 123

Integer “123”
=> 123

i.e. the usual case is to have a method with the same name as a class,
and use that method as a kind of constructor.

Note, however, that you have to call it with arguments, or as Foo() or
self.Foo. A bare Foo by itself is treated as a constant.

Foo = 42
=> 42

def Foo; 99; end
=> nil

Foo
=> 42

Foo()
=> 99

self.Foo
=> 99

Regards,

Brian.

On Sun, Jan 29, 2012 at 05:18:50PM +0900, Ryan D. wrote:

end


P.S. I tried to do the above in yaml and it just didn’t feel as funny. Close
tags make things funnier.

So . . . you are not only a trollish jackass, but also deficient in your
understanding of English. Thanks for the update.

On Jan 29, 2012, at 12:10 , Chad P. wrote:

describe “Foo” do
understanding of English. Thanks for the update.
Yes, I’m obviously deficient in my understanding of English… You’re
welcome.

Why compare “storing [things] in a hash” with “dynamically [storing
(other?) things] to new hashes”?

On Fri, Jan 27, 2012 at 7:56 AM, Chad P. [email protected] wrote:

end

def greet
return “Hello, #{@name}”
end
end

Object.const_set bar, klass

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

If the class name is dynamic (meaning, it comes from some input
outside the program code) then the only reasonable thing is to derive
the definition of the class also from input. Having a class with a
dynamic name whose behavior is always defined in the same way would be
useless. Also, you would want to have several of them because
otherwise a single class with a fixed name and input driven definition
would be sufficient. If you have multiple classes with dynamic
definitions (and probably names as well, but they could also be
unnamed) then you need a way to select them. This could be something
which is used as key in a Hash (quite efficient) - but you could also
have a dynamic mechanism, where each class is asked whether it feels
responsible.

cl = []

cl << Class.new do
def self.my_job?(x)
x % 2 == 0
end

def show(x)
  printf "I EVEN show you %d.\n", x
end

end

cl << Class.new do
def self.my_job?(x)
x % 2 != 0
end

def show(x)
  printf "%d is ODD.\n", x
end

end

irb(main):022:0> 5.times do |i|
irb(main):023:1* cls = cl.find {|c| c.my_job? i}
irb(main):024:1>
irb(main):025:1* if cls
irb(main):026:2> obj = cls.new
irb(main):027:2> obj.show i
irb(main):028:2> else
irb(main):029:2* $stderr.printf “Nobody wants %d\n”, i
irb(main):030:2> end
irb(main):031:1> end
I EVEN show you 0.
1 is ODD.
I EVEN show you 2.
3 is ODD.
I EVEN show you 4.
=> 5

But all this does not seem the case for the OP’s piece of code, so
we’re rather abducting the thread. :slight_smile:

Kind regards

robert

On Fri, Jan 27, 2012 at 7:56 AM, Chad P. [email protected] wrote:

You’re right, that’s much better – apart from the fact I have yet to
come up with a single good reason for dynamic class names.

A pre-pre-alpha project of mine – http://github.com/gsinclair/rgeom
– implements a DSL to describe geometric shapes, which can then be
rendered into an image, given appropriate inputs. (The DSL describes
the inputs etc.)

e.g.

shape :polygon, … { definition stuff I can’t even remember } …

The effect of that is to create a class called RGeom::Shape::Polygon
with some methods defined. It all uses eval or class_eval or
whatever.

That class needs to be named class because more methods need to be
defined. So you need to be able to do

class RGeom::Shape::Polygon
def construct(parameters)

end
# etc.
end

Maybe there’s some other way I could do it that doesn’t need a
dynamically named class, but I sure ain’t looking for a different way.

Gavin