Re: Proposed change to BC iterator parameters [limitedness]

Re: Proposed change to BC iterator parameters [limitedness]

[Georg Bauhaus]

amado.alves <amado.alves@netcabo.pt> wrote:
: 
:
: I do like indefinite formals, but I pass well
: without limited ones. Most limited formals I've seen in libraries
: are accompanied by a formal assignment operation or some such,
: which prety much defeats the purpose of their (formal) limitedness,
: i.e. their logic is in clash with their definition. 

Sometimes I dearly wanted limited records but was defeated
by the library that could not store them (storing them was the
intention):

  type T(x: access D) is tagged limited private;

I want x to be constant plus initialised once and for all,
so access discriminants are just fine, but T has to
be limited then. Which would have been o.K., but not every library
allows this.

What should I do? Use pointers to the records? Afaics, this leads to
allocators or library level declarations (not always possible when
an unkown number of objects' lives start during the program's run?)
or 'unchecked_access.

Or use record compontens of
  type D_Ptr is access constant D;
and get rid of the access discriminants, and have a definite type?
How do I prevent then that tagged records can be declared but not
initialised?

Any suggestion would be very welcome.


Thanks,
-- Georg

RE: Proposed change to BC iterator parameters [limitedness]

[amado.alves]

<<Sometimes I dearly wanted limited records but was defeated
by the library that could not store them (storing them was the
intention):...>>

I think there are (container) libraries that accept limited element types. And some libs that dont can easily (?) be changed in that direction. But as I indicated I think it is 'unatural' to store values of a limited type. For me it does not make sense to put constants in a container. So my advice can only be: rethink your program.

Re: Proposed change to BC iterator parameters [limitedness]

[Georg Bauhaus]

amado.alves <amado.alves@netcabo.pt> wrote:
: <<Sometimes I dearly wanted limited records but was defeated
: by the library that could not store them (storing them was the
: intention):...>>
: 
: I think there are (container) libraries that accept limited
element types.

Charles does (some of it).

: And some libs that dont can easily (?) be changed
: in that direction.  But as I indicated I think it is 'unatural'
: to store values of a limited type. For me it does not make sense
: to put constants in a container. So my advice can only be: rethink
: your program.

I tried, limitedness is only an implication of having access
discriminants in tagged types, which fulfil the requirements
(see type T below):
- "There are three constant links to other objects in these objects".
- "You will have to provide initial values for these links, we cannot
   have dangling pointers here.".

given

  type T
    (look_here: access D;
     look_there: access E;
     and_also_over_there: access D)
  is tagged limited
      record
	 variable_part_1: Some_Type;
	 variable_part_2: Some_Other_Type;
      end record;
   
  ...

The thing is not that I want to store constant instances of
T, I will have to have instances available with both constant
component parts and variable component parts, as above.  To me,
this type seemed natural.  Or is it not, given the requirements
from above?

Where do I store these instances? They must live somewhere...

The "solutions" I have now are using a _comment_ indicating that
clients _should_ use a constructor function, here is one of the
solutions that doesn't use pointers to T objects:

   type T is tagged private;
   --  use make!

   function make
    (look_here: D;
     look_there: E;
     and_also_over_there: D) return T;

where the full view of T contains pointer fields, and make provides
'(unchecked)_access values for them.  But "--  use make!" is not
enforcable by a compiler, while

   type T(<>) is tagged limited private;

or some such will not allow me or anyone else to declare T objects
without initialisation (for any access parameters). Which is what
I found desirable, I can then rely on the language and assume
that T instances will have been initialised, without relying on
programmers obeying a comment about a related function.


I'm stuck.
(Thinking around corners: deriving a definite T from Controlled
inside a generic wich has make(...) from above as a formal subprogram
wich is then called during Initialise of T?  Phew...)

-- Georg

RE: Proposed change to BC iterator parameters [limitedness]

[amado.alves]

<<: I think there are (container) libraries that accept limited
element types.

Charles does (some of it).>>

So perhaps you should consider using it.

<<
: ...For me it does not make sense
: to put constants in a container. So my advice can only be: rethink
: your program.

I tried, limitedness is only an implication of having access
discriminants in tagged types...>>

I know. Big annoyance of Ada. The root of all 'unnaturalness'. Often I also end up specifying things 'above' the language like you did with "Make".

RE: Proposed change to BC iterator parameters [limitedness]

[amado.alves]

<<
  type T
    (look_here: access D;
     look_there: access E;
     and_also_over_there: access D)
  is tagged limited...
>>

Since your working with a container library anyway a cleaner solution might be to create containers for types D and E and replace the access discriminants above with the corresponding pointers (iterators).

Re: Proposed change to BC iterator parameters [limitedness]

[Marin David Condic]

Here's a question because I have not looked at either of these libraries 
  in any detail: Does either Charles or Booch support some kind of 
persistance of objects? By which I mean do they store/retrieve from a 
file or serialize to/from a stream such that they could be put into a 
file readily?

MDC

amado.alves wrote:

> 
> Charles does (some of it).>>
> 
> So perhaps you should consider using it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Trying is the first step towards failure."
         --  Homer Simpson

======================================================================

Re: Proposed change to BC iterator parameters [limitedness]

[Robert A Duff]

"amado.alves" <amado.alves@netcabo.pt> writes:

> I think there are (container) libraries that accept limited element
> types. And some libs that dont can easily (?) be changed in that
> direction. But as I indicated I think it is 'unatural' to store values
> of a limited type. For me it does not make sense to put constants in a
> container. So my advice can only be: rethink your program.

Heh?  Limited is not the same thing as constant.  It makes perfect sense
to store limited objects in containers.  *Some* containers require
copying to get the data in and out of the container; limited components
do not make sense in *that* case.  But other containers can deal with
limited types just fine.

Why do you think Ada allows arrays of tasks?  An array is a container,
and tasks are about as limited as you can get!

- Bob

RE: Proposed change to BC iterator parameters [limitedness]

[amado.alves]

<<
> I think there are (container) libraries that accept limited element
> types. And some libs that dont can easily (?) be changed in that
> direction. But as I indicated I think it is 'unatural' to store values
> of a limited type. For me it does not make sense to put constants in a
> container. So my advice can only be: rethink your program.

Heh?  Limited is not the same thing as constant.>>

I think the original poster wanted limited for logical constants.

<<It makes perfect sense to store limited objects in containers.>>

Not "perfect" to me ;-)

<<*Some* containers require
copying to get the data in and out of the container;>>

Strictly all containers do. The difference is when. At declaration, at elaboration, at run time...

<<... limited components
do not make sense in *that* case.  But other containers can deal with
limited types just fine.

Why do you think Ada allows arrays of tasks?>>

I don't know. I would be happy with pointers to tasks or some such. For uniformity. You can have an array of exceptions ids, but not of exceptions.

<<An array is a container,>>

I can say any object is a container. An uni-elementary one.

<<...and tasks are about as limited as you can get!>>

Yes, unfortunately.

Re: Proposed change to BC iterator parameters [limitedness]

[Robert A Duff]

"amado.alves" <amado.alves@netcabo.pt> writes:

>... You can have an array of exceptions ids, but not of exceptions.

Yes, and that's a horrible kludge.  The language would be much simpler,
and also more powerful, if exceptions were first-class objects (of type
Exception'Class or some such).

- Bob

Re: Proposed change to BC iterator parameters [limitedness]

[Jeffrey Carter]

Marin David Condic wrote:

> Here's a question because I have not looked at either of these libraries 
>  in any detail: Does either Charles or Booch support some kind of 
> persistance of objects? By which I mean do they store/retrieve from a 
> file or serialize to/from a stream such that they could be put into a 
> file readily?

The PragmAda Reusable Components allow structures of limited definite 
types. They do not support persistence directly, because that can easily 
be implemented with an iterator.

-- 
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69

Re: Proposed change to BC iterator parameters [limitedness]

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

> Here's a question because I have not looked at either of these
> libraries in any detail: Does either Charles or Booch support some
> kind of persistance of objects? By which I mean do they store/retrieve
> from a file or serialize to/from a stream such that they could be put
> into a file readily?

The BCs support streams.

Mark Bond worked on extending the BCs to provide persistence, I
haven't rolled the work into the mainstream ..
http://www.pushface.org/components/bc/contrib/bond/

-- 
Simon Wright                               100% Ada, no bugs.