On Nov 9, 2011, at 5:29 PM, Fily Salas wrote:

> Marc Heiler wrote in post #1031087:
>>> bad because I could't figure this out by my self
>>=20
>> You just need to write more ruby code.
>>=20
>> Ideally, write small classes that solve a given problem,
>> then re-use those classes to make a larger project.
>=20
> Do you know of any tutorials where you can actually practice Ruby in
> actual projects?  Not tutorials on the Ruby syntax (projects using =
Ruby)
>=20
>=20
> I have another question, in Peters code he used "private" but if I
> remove it, it actually works can someone explain the use of private
> here, is this the way of making a private def in Ruby?

You make methods private if you don't want to expose them on the =
object's public API. Note that because of Ruby's dynamic nature, =
'private' does *not* mean that you can't call the method from the =
outside, it just discourages it. Ruby enforces that private methods can =
only be called without an explicit receiver, i.e., you can not call it =
with a dot directly in front of it. If 'calc' is a private method of =
Class A, then you cannot do this:

A.new.calc # =3D> fails

However, inside of an instance of A, you can call calc without =
specifying a receiver (because self will be used implicitly). If you =
still want to call a private method from the outside, the common way is =
to use #send. Therefore, you could do this:

A.new.send(:calc)

Typically, you will make methods private if you don't intend them to be =
called from the outside. Use them to express your intentions more =
clearly and help others (or your future self) to understand your code =
better.



> ----------------------------------
>  private
>=20
>  def calc
>    sheet_width =3D 60
>    sheet_length =3D 120
>=20
>    parts_y =3D sheet_width / (@part_width + @kerf)
>    parts_x =3D sheet_length / (@part_length + @kerf)
>     puts parts_y * parts_x
>  end
>=20
> ---------------------------------
>=20
> --=20
> Posted via http://www.ruby-forum.com/.
>=20