[rhg-discussion] Hello

Clifford Caoile piyokun at gmail.com
Mon Mar 20 19:32:58 EST 2006


Here's most of Jim Driscoll's suggestion in diff format. I say most
because he has multiple suggestions for some points.

Index: chapter02.txt
===================================================================
--- chapter02.txt	(revision 8)
+++ chapter02.txt	(working copy)
@@ -11,7 +11,7 @@

 What are the required conditions to make sure objects can exist? Many
 explanations can be given but in reality there are three conditions that must
-be respected:
+be obeyed:

 # Being able to differentiate itself from the rest (having an identity)
 # Being able to reply to requests (methods)
@@ -147,8 +147,8 @@
 TYPE(str);             /* the return value is T_STRING */
 </pre>

-The name of these `T_xxxx` flags is directly linked to the type name, like
-`T_STRING` for `struct RString` and `T_ARRAY` for `struct RArray`.
+The names of these `T_xxxx` flags are directly linked to the corresponding type
+name, like `T_STRING` for `struct RString` and `T_ARRAY` for `struct RArray`.

 The other member of `struct RBasic`, `klass`, contains the class this object
 belongs to. As the `klass` member is of type `VALUE`, what is stored is (a
@@ -170,14 +170,14 @@
 handle all different types of structure via `VALUE`. If you cast a pointer to
 a structure to `VALUE`, as the type information does not remain, the compiler
 won't be able to help. Therefore we have to manage the type ourselves. That's
-the consequences for being able to handle all the structure types in a unified
+the consequence of being able to handle all the structure types in a unified
 way.

-OK, but the used structure is defined by the class so why is the structure
+OK, but the used structure is defined by the class so why are the structure
 type and class are stored separately? Being able to find the structure type
 from the class should be enough. There are two reasons for not doing this.

-The first one is, I'm sorry for contradicting what I said before, but in fact
+The first one is (I'm sorry for contradicting what I said before), in fact
 there are structures that do not have a `struct RBasic` (i.e. they have no
 `klass` member). For example `struct RNode` that will appear in the second
 part of the book. However, `flags` is guaranteed to be in the beginning
@@ -193,7 +193,7 @@

 h4. The use of `basic.flags`

-As limiting myself to say that `basic.flags` is used for different things
+As limiting myself to saying that `basic.flags` is used for different things
 including the type of structure makes me feel bad, here's a general
 illustration for it (diagram 5). There is no need to understand everything
 right away, I just wanted to show its uses while it was bothering me.
@@ -210,7 +210,7 @@
 As I said, `VALUE` is an `unsigned long`. As `VALUE` is a pointer, it may look
 like `void*` would also be all right, but there is a reason for not doing
 this. In fact, `VALUE` can also not be a pointer. The 6 cases for which
-`VALUE` is not a pointer are the followings:
+`VALUE` is not a pointer are the following:

 # small integers
 # symbols
@@ -225,12 +225,12 @@

 As in Ruby all data are objects, integers are also objects. However, as there
 are lots of different instances of integers, expressing them as structures
-would risk to slow down the execution. For example, when incrementing from 0
+would risk slowing down execution. For example, when incrementing from 0
 to 50000, just for this creating 50000 objects would make us hesitate.

 That's why in `ruby`, to some extent, small integers are treated specially and
 embedded directly into `VALUE`. "small" means signed integers that can be held
-in `sizeof(VALUE)*8-1` bit. In other words, on 32 bits machines, the integers
+in `sizeof(VALUE)*8-1` bits. In other words, on 32 bits machines, the integers
 have 1 bit for the sign, and 30 bits for the integer part. Integers in this
 range will belong to the `Fixnum` class and the other integers will belong to
 the `Bignum` class.
@@ -268,7 +268,7 @@

 What are symbols?

-As this question if quite troublesome to answer, let's start with the reasons
+As this question is quite troublesome to answer, let's start with the reasons
 why symbols were necessary. First, let's start with the `ID` type used inside
 `ruby`. It's like this:

@@ -287,7 +287,7 @@

 In language implementations, there are a lot of names to handle. Method names
 or variable names, constant names, file names in class names... It's
-troublesome to handle all of them as strings (`char*`), because of of memory
+troublesome to handle all of them as strings (`char*`), because of memory
 management and memory management and memory management... Also, lots of
 comparisons would certainly be necessary, but comparing strings character by
 character will slow down the execution. That's why strings are not handled


On 3/21/06, Jim Driscoll <j at rjimlad.org> wrote:
> Hi all,
>
> Ruby knowledge: fair
> C knowledge: good
> Languages: English (British)
>
> I have to say this seems like a worthy project (and an excellent
> reference book) based on chapter two. So far, I'd say:
>
> - I think that "three conditions that must be respected" should
> perhaps be "three conditions that must be obeyed" or indeed "must be
> true".
> - "The name of these T_xxxx flags is directly linked to the type
> name" should read "The names of these T_xxxx flags are directly
> linked to the [corresponding] type name" or maybe just "The names of
> these T_xxxx flags correspond to type names"
> - "That's the consequences for being able to handle all the structure
> types in a unified way." should read "That's the consequence of being
> able to handle all the structure types in a unified way."
> - It's normally considered better style to write "okay" rather than "OK"
> - "so why is the structure type and class are stored separately?"
> should read "so why are the structure type and class stored separately?"
> - "The first one is, I'm sorry for contradicting what I said before,
> but in fact" should perhaps read "The first one is (I'm sorry for
> contradicting what I said before), in fact", or "The first one is:
> I'm sorry for contradicting what I said before, but in fact"
> - "so finding a structure from a class would require to keep the
> correspondence" should read "so finding a structure from a class
> would require keeping the correspondence"
> - "As limiting myself to say that basic.flags is used for different
> things" should read "As limiting myself to saying that basic.flags is
> used for different things" or perhaps "As just saying that
> basic.flags is used for different things"
> - "The 6 cases for which VALUE is not a pointer are the followings"
> should read: "The 6 cases for which VALUE is not a pointer are the
> following"
> - "expressing them as structures would risk to slow down the
> execution" should read "expressing them as structures would risk
> slowing down execution [speed]"
> - ""small" means signed integers that can be held in sizeof(VALUE)
> *8-1 bit" should read ""small" means signed integers that can be held
> in sizeof(VALUE)*8-1 bits"
> - "As this question if quite troublesome to answer" is a typo: should
> be "As this question is quite troublesome to answer"
> - "because of of memory management and memory management and memory
> management… " I don't know quite what this is trying to say, but it's
> definitely got one "of" too many.
>
> ...and that's all as far as I've read (the beginning of the "Methods"
> section.
>
> Jim
>
>
>
> _______________________________________________
> rhg-discussion mailing list
> rhg-discussion at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rhg-discussion
>



More information about the rhg-discussion mailing list