eiffelroom - Article - Comments

Note that RTMS is a macro

manus_eiffel — Thu, 19 Jun 2008 22:43:37 -0700

Note that RTMS is a macro and evaluate twice its argument, so for efficiency it should be:

cpp_get_text: STRING is

        -- Get some dummy text

    external

        "C++ inline use <string>"

    alias

        "[

         std::string a = "dummy";

         char *c_str = (char*) a.c_str();

         return RTMS(c_str);

        "]

    end

After having a problem with

patrickr — Wed, 18 Jun 2008 13:27:07 -0700

After having a problem with creating a STRING from a std::string (c++): Here's the solution

cpp_get_text: STRING is

        -- Get some dummy text

    external

        "C++ inline use <string>"

    alias

        "[

         std::string a = "dummy";

         return RTMS(((char*)a.c_str()));

        "]

    end

It won't be collected until

ted_eiffel — Wed, 11 Jun 2008 20:19:54 -0700

It won't be collected until eif_wean() is called.

When you eif_protect()

clemahieu — Wed, 11 Jun 2008 13:52:26 -0700

When you eif_protect() something in C, is this considered a reachable reference to the GC? i.e. if the Eiffel side of code loses reachability to an object that was passed to C and eif_protect'ed, will it ever be collected?

Prefixes for assemblies

ruihua — Mon, 07 Apr 2008 01:32:07 -0700

Thank you for your hint. I did not know about assembly-wide prefixes. I think it's a good alternative to resolve name clashes.

Looks Great

peter_gummer — Fri, 04 Apr 2008 14:58:58 -0700

One question, Ruihua. At step 7, instead of renaming individual classes, why didn't you just set assembly-wide prefixes DB4O_ and REFLECTOR_?

Abstract Side Effect

maverick — Thu, 06 Mar 2008 07:28:33 -0800

It seems a little vague to speak of abstract side effect without specifying a model. In this case, I think there is a model and a justification for each positions. In OOSC, Meyer introduce the random number generator as a traversable object. In this case, the corresponding model is composed of a sequence of numbers (about which the invariant may state that the numbers have certain probabilistic distribution) and an integer indicating what is the next number to be returned to the user. In this case, generating a random number is a side effect and, according to CQS principle, should be implemented as a command.

But another possible model may be only a set of possible numbers or a range of numbers. In this case, the specification of a routine that generate a random numbers may be non deterministic without ever changing the abstract state of an object.

An operation which returns a non-deterministic result is a common thing in B but one could argue that B does not have CQS and does not have a need for it since no operation invocation can be performed in expressions. Back to Eiffel, it certainly is arguable whether non deterministic specification is the right thing for a query but it certainly is legal even according to CQS.

Cheers!

Simon

To see something, you might add a loop

Jocelyn Fiat — Thu, 29 Nov 2007 10:06:00 -0800

To see something, I would just add the following points:

1) add THREAD_CONTROL to the inherited class for SAMPLE 2) at the end of make, you could add (for instance)

from until False loop
    print (".")
    sleep (1_000_000_000)
end

Will update tutorial

bayt — Sun, 04 Nov 2007 09:26:40 -0800

Thanks Neal,

I will integrate this info in the tutorial on Goanna's Origo page too.

Great Tutorial

neallester — Sun, 04 Nov 2007 09:19:52 -0800

Thank you for doing this, Till. One thing I'd like to add is that the parameter collections are for validating the semantics of a submitted form, not for validating user input.

Mandatory Parameter Collection - These are mandatory at the form processing level, not required fields in the form the user sees. Typically, these are a html hidden elements used to verify that some system state is the same at form processing time as it was at form generation time. For example, it might contain the user name of a logged in user to prevent them from submitting a form, logging out, logging in as a new user, and then using the back button to resubmit the previously generated form for the previous user.

Required Parameter Collection - These are html elements which must be present in the form for correct processing to occur or whose absence indicates a serious bug in the form generation routine or an attack on the web site. This doesn't necessarily mean that the user must provide a value for the element. "address_line_2" on a registration page might be an example of a required parameter for which no user input would be required.

Optional Parameter Collection - These are elements whose absence from a submitted form is expected sometimes. No processing for this parameter will occur if they are not present in the form.

Add If Absent Parameter Collection - These are elements whose absence from a form has meaning. html checkbox elements provide a typical example. If they are not present in the form submittal, a PARAMETER_PROCESSING_RESULT for them is added so that the appropriate processing for their unchecked state will occur.

Validating User Input

Each GOA_REQUEST_PARAMETER is responsible for validating the input it receives from the user. Since receiving invalid input is expected, this does not interrupt request processing. Typically, invalid user input produces

"not PARAMETER_PROCESSING_RESULT.is_value_valid"

which in turn triggers the redisplay of the form with an error message. Several GOA_REQUEST_PARAMETER descendents implement this behavior for common data types.

Church numerals

colin-adams — Tue, 05 Jun 2007 07:28:54 -0700

Couldn't you make it more complicated by using Church numerals? Colin Adams

Fixed ...

schoelle — Tue, 05 Jun 2007 00:16:23 -0700

You are right, SET[G] would not type check. Was a typo. I have fixed it in the article.

Signature of i_th_power

doenniu — Mon, 04 Jun 2007 12:10:58 -0700

I think that the signature of i_th_power has to be:

i_th_power (i: INTEGER): SET [ANY]

I like NAT, that helps me on my endless quest to write a program that counts from 1 to 5 in the most complicated way:

(nat_to_integer (create {NAT [NAT [BOOLEAN]]}) |..| nat_to_integer (create {NAT [NAT [NAT [NAT [NAT [NAT [BOOLEAN]]]]]]})).do_all (agent (a_int: INTEGER) do print (a_int.out + "%N") end)

My summary

doenniu — Thu, 10 May 2007 15:05:44 -0700

Together with my comment "What is the question?", I think the whole discussion comes down to the question if you agree with the following statement or not:

"A random number does not mean much by itself; it must be understood in relation to its predecessors and successors in the sequence" (Meyer, OOSC2, p. 755).

If you agree with the statement, then you should apply CQS also for random numbers like it is described in OOSC2, using

random: RANDOM

...

random.forth

l_item := random.item

If you disagree, then you should be able to write a feature next_random. And as soon as you have that, it doesn't matter how you implement it (therefore you can also implement it using RANDOM or change your implementation later). I for my part disagree with Meyer's statement, that's why I'm using next_random. If you agree with the statement, you shouldn't use the feature.

Quote from Colin:
A principle that must be followed without exception is, in effect, a law
I agree, but the quote you gave says "every object-oriented developer SHOULD apply this principle without exception", not "every object-oriented developer MUST apply this principle without exception" :)

Selective quoting of OOSC2

colin-adams — Thu, 10 May 2007 07:28:50 -0700

I am somewhat bemused by the apparent appeal to OOSC2 (as if it were holy scripture) in order to support the case for making random numbers an exception to the CQS principal. This is highly selective quoting.

For a start, on p. 758, Professor Meyer says: "every object-oriented developer should apply this principle without exception".

Even more bemusing is that back on page 754-755, he explicitly gives the example of random numbers.

A principle that must be followed without exception is, in effect, a law.

Colin Adams