[Courses] [Ruby] Lesson 1: Introduction, Classes, Objects, and Variables

[Akkana Peck]

Laurel Fan writes:
> 2. For those who know other programming languages, what are some ways
>    that Ruby is different from other languages you know?

The biggest difference is that everything is a class -- even
numbers. Being able to say something like -1942.abs instead of
abs(-1942) or Math.abs(-1942) is neat. I like it. One of the
confusing things about Python (though I do like Python a lot)
is figuring out, especially with strings, when I need to say
s.replace("foo", "bar") vs. string.replace(s, 'foo', 'bar');
or sometimes needing to say something like Integer(-1942).abs
(i.e. some things are already an object, but other things you
have to convert into an object). Ruby is more consistent.

The expression interpolation is cool, too: being able to say
puts "Good night, #{name}", where name is the name of one of
the function arguments, is very useful.

One thing I don't like as much is the if ... elsif ... end
structure. To be honest. I like C-style braces best, though
Python's colon-plus-indentation works well too. "end" isn't
so bad, but as someone who uses lots of different languages,
it drives me batty to try to remember which languages use
"else if", which "elif", which "elsif", etc. ... and I wish
people would just stop designing languages that way.

Blocks and "yield" seem like an unnecessary complexity, but
perhaps eventually I'll see the point. (The examples in the
book don't really justify why this is needed.)

> 3. What's the difference between an instance variable and class
>    variable?

An instance variable belongs to a specific object (an instance
of some class). Each instance has its own copy of each instance
variable. A class variable is shared by the whole class; the whole
class only has one copy, and each instance of the class can see
the value of that class variable.

> 4. What's the difference between a variable and an attribute?

Attributes look like instance variables to code outside the class,
but they're actually implemented as functions (sometimes? Always?)
If you use attr_reader (or do the same thing by hand), then the
function that implements the attribute that's visible outside
the class will probably just return the value of the instance
variable of the same name.

> 1. Defining classes: photo gallery.  Think about what classes you
>    would need to define to write a web photo gallery application.  For
>    now, don't think of the actual implementation details of handling
>    web requests, displaying images, etc.  Obviously you'll need to
>    represent a photo.  What attributes does it have?  What other
>    objects do you need?

Okay, just a quick start on this.
(Note: I have my own simple web photo gallery code, a really basic
setup, that I wrote in perl a long time ago and later translated
into PHP. So I've thought about this a little, though my
implementation is just a bare-bones one and doesn't do most
of what I'll suggest here.)

The only thing the photo object absolutely needs to have is the
filename (the thing that's going to go into the IMG tag in the page).

But there are some other things it really ought to have:

* Something to put in the ALT attribute of the IMG tag on the page
  (a few words of description).
* A longer description (may be blank) describing what the photo is.
* Width and Height of the image.
* EXIF information, if any (date/time, size, what camera was used,
  exposure data like aperture and shutter speed)
* Other sizes which might be available (thumbnail? fullres?)
* Maybe information on copyright or how to order a print,
  depending on the intended user of the gallery.

Other objects:
* gallery: information about this particular gallery, mainly a
  title indicating what the pictures are, like "Vacation in Hawaii",
  maybe a date, maybe some descriptive text, maybe cross-references
  to other similar galleries like "Vacation in Tahiti".
* Some way to store links back to the top level, and possibly
  to other galleries. That might belong in the gallery object too,
  but there might be other navigation information needed which
  might justify some other object.
* Something that can handle layout: things like how many images can
  we display per row, and where are we in the row?

I haven't done anything on the /proc suggestion -- though it does
sound like a fun exercise. But I ran out of time and decided it
was better to post what I had than keep it sitting any longer
waiting until I had time to fiddle with /proc.

	...Akkana