Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel_software] Re: How to specify manifest types in EiffelStudio?

Expand Messages
  • Alexander Kogtenkov
    ... The whole idea behind my example is that the class is both expanded and attributeless. Because of that there is no way to create an object in some other
    Message 1 of 10 , Sep 1, 2010
    • 0 Attachment
      Helmut Brandl wrote:

      >> expanded class HASH_MAP_VALIDATOR [V,KEY->HASHABLE] feature
      >> have_unique_keys (...) ...
      >> end
      >>
      >> class HASH_MAP[V,KEY->HASHABLE] create from_pairs ... feature
      >> validator: HASH_MAP_VALIDATOR [V,KEY]
      >> from_pairs (pairs: LIST[TUPLE[V,KEY]])
      >> require
      >> validator.have_unique_keys(pairs)
      >
      > I have 2 remarks with respect to that.
      >
      > 1. validator is a public attribute of the class. But the client of the
      > HASH_MAP cannot use it, because the object is not yet constructed.
      > Therfore the client is not able to verify the precondition. Clearly the
      > client can declare an own local variable of type HASH_MAP_VALIDATOR and
      > hope that `default_create' creates in the same manner as HASH_MAP uses
      > it. But by looking only at the interface part of HASH_MAP, the client
      > does not know how HASH_MAP creates that attribute.

      The whole idea behind my example is that the class is both expanded and
      attributeless. Because of that there is no way to create an object in "some
      other manner" - it's always equal to any other instance.

      > 2. There is a rule in the ECMA standard which says that a precondition
      > must not use unqualified calls. Your proposal violates that rule. Is a
      > modification of that rule expected which sounds like:
      >
      >> Unqualified calls in preconditions of a creation procedure are allowed
      > only if the unqualified call calls an attribute of expanded type which
      > will be used in the class only as created by default_create.

      As I noted above it should be both expanded and attributeless.

      > Furthermore even if you introduce ephemeral classes it seems a bit of an
      > overkill to write an extra class just to get the precondition checked.
      > Sounds a little bit complicated, doesn't it?

      It does. But before it can be changed we need a way to indicate that a
      particular feature can be used in the precondition of a creation procedure
      or that it can be used in an objectless feature call.

      Regards,
      Alexander Kogtenkov
    Your message has been successfully submitted and would be delivered to recipients shortly.