How to return an empty aggregate

How to return an empty aggregate

[Maciej Sobczak]

In my previous post I had the following:

      type Concrete is new Middle with null record;

      function Make_Concrete return Concrete is
         C : Concrete;
      begin
         return C;
      end Make_Concrete;

I would like to return the empty(?) aggregate instead of the dummy
local variable.
Is there a way to do this?

The following:

        return Concrete' (others => <>);

results in segmentation fault on my system (compiler version as
before).

Extended return with null statement works fine, but I would like to
understand the language corners involved with the aggregate.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[Anh Vo]

On Apr 1, 4:58 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> In my previous post I had the following:
>
>       type Concrete is new Middle with null record;
>
>       function Make_Concrete return Concrete is
>          C : Concrete;
>       begin
>          return C;
>       end Make_Concrete;
>
> I would like to return the empty(?) aggregate instead of the dummy
> local variable.
> Is there a way to do this?
>
> The following:
>
>         return Concrete' (others => <>);
>
> results in segmentation fault on my system (compiler version as
> before).
>

Did you get seg fault during run time or the compiler crashed with seg
fault?

By the way, the return statement should be flagged as syntax error due
to missing the base type Middle.

> Extended return with null statement works fine, but I would like to
> understand the language corners involved with the aggregate.

This must me the compiler bug. The program should behave the same way.

AV

Re: How to return an empty aggregate

[Dmitry A. Kazakov]

On Tue, 1 Apr 2008 04:58:06 -0700 (PDT), Maciej Sobczak wrote:

> In my previous post I had the following:
> 
>       type Concrete is new Middle with null record;
> 
>       function Make_Concrete return Concrete is
>          C : Concrete;
>       begin
>          return C;
>       end Make_Concrete;
> 
> I would like to return the empty(?) aggregate instead of the dummy
> local variable.
> Is there a way to do this?

   (Middle with null record);

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How to return an empty aggregate

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> In my previous post I had the following:
>
>       type Concrete is new Middle with null record;
>
>       function Make_Concrete return Concrete is
>          C : Concrete;
>       begin
>          return C;
>       end Make_Concrete;
>
> I would like to return the empty(?) aggregate instead of the dummy
> local variable.

return (null record);

should work.

- Bob

Re: How to return an empty aggregate

[Adam Beneschan]

On Apr 1, 5:54 am, Anh Vo <anhvofrc...@gmail.com> wrote:
> On Apr 1, 4:58 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>
>
>
> > In my previous post I had the following:
>
> >       type Concrete is new Middle with null record;
>
> >       function Make_Concrete return Concrete is
> >          C : Concrete;
> >       begin
> >          return C;
> >       end Make_Concrete;
>
> > I would like to return the empty(?) aggregate instead of the dummy
> > local variable.
> > Is there a way to do this?
>
> > The following:
>
> >         return Concrete' (others => <>);
>
> > results in segmentation fault on my system (compiler version as
> > before).
>
> Did you get seg fault during run time or the compiler crashed with seg
> fault?
>
> By the way, the return statement should be flagged as syntax error due
> to missing the base type Middle.

If you're talking about the last return statement:

   return Concrete' (others => <>);

why would this be a syntax error?  I don't know of any language rule
that would require a reference to "Middle" to be present, if that's
what you're saying.

As far as I can tell, what Maciej is trying to do is perfectly fine,
there aren't any language corners that would cause a problem, and the
compiler is misbehaving.

                            -- Adam

Re: How to return an empty aggregate

[Maciej Sobczak]

On 1 Kwi, 19:18, Adam Beneschan <a...@irvine.com> wrote:

> As far as I can tell, what Maciej is trying to do is perfectly fine,
> there aren't any language corners that would cause a problem, and the
> compiler is misbehaving.

Looks like this is related to my previous bug report. The smallest
test case I've found is:

procedure A is

   type Base_1 is interface;
   type Base_2 is interface;
   type Middle is Interface and Base_1 and Base_2;

   type Derived is new Middle with null record;

   function Make_Derived return Derived is
   begin
      return Derived' (others => <>);
   end Make_Derived;

   D : Base_1'Class := Make_Derived;

begin
   null;
end;

This compiles and runs fine.
After changing the order of progenitors in the definition of Middle
(or changing the type of D to Base_2'Class) the program still
compiles, but fails with segfault at runtime - this, however, takes a
couple of seconds.

Time for another entry in bugzilla.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[Maciej Sobczak]

On 1 Kwi, 17:00, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> return (null record);

Same thing - segfault at runtime depending on the order of progenitors
in interface composition (see my reply to Adam).

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 2, 3:19 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 1 Kwi, 17:00, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> > return (null record);
>
> Same thing - segfault at runtime depending on the order of progenitors
> in interface composition (see my reply to Adam).
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Sorry, maybe I am missing something but what's practical sense of
having non-abstract null record implementation of interface(s)?  I am
curious if there is real-life implication of such a construct?

George.

Re: How to return an empty aggregate

[Maciej Sobczak]

On 3 Kwi, 07:02, george.p...@gmail.com wrote:

> Sorry, maybe I am missing something but what's practical sense of
> having non-abstract null record implementation of interface(s)?

Stateless strategy patterns?
Factories?
Finite state machines (no need for state within state)?

Actually, most of the design patterns I can think of make sense in
some stateless form, because the concrete *type* of the object is
often enough to play the role of a state at some higher level.

Interfaces are more about operations than about data.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 3, 5:09 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 3 Kwi, 07:02, george.p...@gmail.com wrote:
>
> > Sorry, maybe I am missing something but what's practical sense of
> > having non-abstract null record implementation of interface(s)?
>
> Stateless strategy patterns?
> Factories?
> Finite state machines (no need for state within state)?
>
> Actually, most of the design patterns I can think of make sense in
> some stateless form, because the concrete *type* of the object is
> often enough to play the role of a state at some higher level.
>

Maybe I put my question incorrectly.  I did not mean challenge those
concepts in purity.  Good example is a factory.  Should it have a
mechanism to register-unregister itself?  Would it imply either
deriving from something like Finalization.Controlled or the other
root, or putting some meat into the object itself?  In addition such
objects make sense in singleton form and likely involve some sort of
guarding mutexes or be implemented as protected or tasks.  BTW in C++
empty factory class will be fine due to implied constructor/
destructor.

> Interfaces are more about operations than about data.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: How to return an empty aggregate

[Maciej Sobczak]

On 4 Kwi, 17:38, george.p...@gmail.com wrote:

> Good example is a factory.  Should it have a
> mechanism to register-unregister itself?

Not necessarily. I might be as well selected at startup time by some
other entity (in which case it is also a strategy).

> In addition such
> objects make sense in singleton form

Yes and no.
Yes, because it does not make any sense to destroy them and create
again.
No, because it is *not harmful* to destroy and create them again (see
also the monostate pattern):

F : Factory'Class := Make_Funny_Factory;
Obj : Object := F.Make_Object;

Above, factory F is a transient entity that is used just to create one
object. It might be a singleton as well, but does not have to.

> and likely involve some sort of
> guarding mutexes or be implemented as protected or tasks.

If it's stateless, then it does not need any protection - there is
nothing to protect.

> BTW in C++
> empty factory class will be fine due to implied constructor/
> destructor.

The empty factory class will be fine in Ada as well.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 4, 4:35 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 4 Kwi, 17:38, george.p...@gmail.com wrote:
>
> > Good example is a factory.  Should it have a
> > mechanism to register-unregister itself?
>
> Not necessarily. I might be as well selected at startup time by some
> other entity (in which case it is also a strategy).
>
> > In addition such
> > objects make sense in singleton form
>
> Yes and no.
> Yes, because it does not make any sense to destroy them and create
> again.
> No, because it is *not harmful* to destroy and create them again (see
> also the monostate pattern):
>
> F : Factory'Class := Make_Funny_Factory;
> Obj : Object := F.Make_Object;
>
> Above, factory F is a transient entity that is used just to create one
> object. It might be a singleton as well, but does not have to.

To me it seems that simple callback will be much more simple and clear
way to achieve the same result.

type Make_Object is access function(Context: Contect_Type) return
Object;

Obj : object := Make_My_Object(Some_Context_Selector);


>
> > and likely involve some sort of
> > guarding mutexes or be implemented as protected or tasks.
>
> If it's stateless, then it does not need any protection - there is
> nothing to protect.

except for reenterance that in most of cases matter for that type of
objects.

>
> > BTW in C++
> > empty factory class will be fine due to implied constructor/
> > destructor.
>
> The empty factory class will be fine in Ada as well.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: How to return an empty aggregate

[Maciej Sobczak]

On 5 Kwi, 01:58, george.p...@gmail.com wrote:

> To me it seems that simple callback will be much more simple and clear
> way to achieve the same result.

It depends where you start with the design. If you start with
stateless concrete factories (or you just see the whole picture right
from the beginning), then callbacks will seem attractive. But if you
start from the user site without knowing up-front what will kind of
factory will be used then 'Class is the OO way to solve the problem.

What will you do with the callback interface if at some point you
discover that stateful factory will be most appropriate? Will you mess
around with local functions that manipulate state from their enclosing
scope? What about many such factories that have distinct states? And
so on.

> > If it's stateless, then it does not need any protection - there is
> > nothing to protect.
>
> except for reenterance that in most of cases matter for that type of
> objects.

If it's stateless, then reentrance is given for free.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 5, 9:48 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 5 Kwi, 01:58, george.p...@gmail.com wrote:
>
> > To me it seems that simple callback will be much more simple and clear
> > way to achieve the same result.
>
> It depends where you start with the design. If you start with
> stateless concrete factories (or you just see the whole picture right
> from the beginning), then callbacks will seem attractive. But if you
> start from the user site without knowing up-front what will kind of
> factory will be used then 'Class is the OO way to solve the problem.
>
> What will you do with the callback interface if at some point you
> discover that stateful factory will be most appropriate? Will you mess
> around with local functions that manipulate state from their enclosing
> scope? What about many such factories that have distinct states? And
> so on.
>
> > > If it's stateless, then it does not need any protection - there is
> > > nothing to protect.
>
> > except for reenterance that in most of cases matter for that type of
> > objects.
>
> If it's stateless, then reentrance is given for free.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Can you provide non-academic example?

Re: How to return an empty aggregate

[Maciej Sobczak]

On 5 Kwi, 18:04, george.p...@gmail.com wrote:

> Can you provide non-academic example?

For the empty record?
I thought I did already. :-)
This might be a challenge, because we have no judge that can say
whether something is academic or not.

Consider a logging system that is designed with OO in mind. There is a
base interface with some operation(s) for logging and a bunch of
concrete implementations for various log destinations - one for disk
file, one for network output, one for database persistency, etc. The
part of the program that does something useful takes Log'Class and
feeds its log entries via given Log'Class parameter to whatever
happens to be a concrete Log implementation - a classic strategy
pattern.

What would you do to... switch the logging off?

I would create the derived (concrete) log that is *empty* and does
nothing and pass it as Log'Class to wherever it is expected.
It cannot be simpler than that.

Is it academic? I would do it at the nearest opportunity.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 5, 5:14 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 5 Kwi, 18:04, george.p...@gmail.com wrote:
>
> > Can you provide non-academic example?
>
> For the empty record?
> I thought I did already. :-)
> This might be a challenge, because we have no judge that can say
> whether something is academic or not.
>
> Consider a logging system that is designed with OO in mind. There is a
> base interface with some operation(s) for logging and a bunch of
> concrete implementations for various log destinations - one for disk
> file, one for network output, one for database persistency, etc. The
> part of the program that does something useful takes Log'Class and
> feeds its log entries via given Log'Class parameter to whatever
> happens to be a concrete Log implementation - a classic strategy
> pattern.
>
> What would you do to... switch the logging off?
>
> I would create the derived (concrete) log that is *empty* and does
> nothing and pass it as Log'Class to wherever it is expected.
> It cannot be simpler than that.

So you derive concrete from not-empty type?

>
> Is it academic? I would do it at the nearest opportunity.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 5, 5:14 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 5 Kwi, 18:04, george.p...@gmail.com wrote:
>
> > Can you provide non-academic example?

I don't really mean to be rude by throwing short answers but was on
the road whole week while conversation is very interesting. So if
provoke some of that apologize. By non-academic I mean you just rip it
from the project you did and past (just snippets) and explain what is
application.  My original remark was due to a fact that I started
looking at all the objects I had written so far and, although use
Factories, Adapters and Relays never found anything that is empty.  I
won't deny there are some out there and that what I would like to see,
given the condition above, otherwise this thread will be endless.

Just scrolling through my code found this little example

   --
   -- Generic Agent Interface
   type Agent_I is limited interface and Disposable_I;
   type Agent_Any is access all Agent_I'Class;

   -- Receive the new data item and determine the state
   procedure Receive (Me : in out Agent_I; Item : Entity_T) is
abstract;
   -- Signal the alarm conditions
   function Alarm (Me : Agent_I) return Alarm_T is abstract;

The agent monitors oncoming entities for conditions that call for
alarm.  System has list of Agents that can be added/removed on the
fly.  Alarms by each agent can be OR'ed or AND'ed to generate the
state of the system. Theoretically one can do Null_Agent_Type that
will do nothing but there is no point in that since empty agent list
will give the same effect.  Any agent implementation has some context
associated, since Entities may get flaky and provoke unnecessary knee
jerk reaction.  Now one can make that into a strategy solution you
mentioned by splitting the Entity stream context into separate item.
Then Agent becomes pure logic machine and that will be "proper" OO
way, but seems impractical for my case though. The reason for that is
that Agent and the way data is conditioned is very inter-related and
generalize that will cause a lot of unnecessary LOCs and spread of
code that should better be kept localized.

More fundamental question is there any payback in separating strategy
and history (context). Which will be then History and Logic I guess?




>
> For the empty record?
> I thought I did already. :-)
> This might be a challenge, because we have no judge that can say
> whether something is academic or not.
>
> Consider a logging system that is designed with OO in mind. There is a
> base interface with some operation(s) for logging and a bunch of
> concrete implementations for various log destinations - one for disk
> file, one for network output, one for database persistency, etc. The
> part of the program that does something useful takes Log'Class and
> feeds its log entries via given Log'Class parameter to whatever
> happens to be a concrete Log implementation - a classic strategy
> pattern.
>
> What would you do to... switch the logging off?

There is some sort of logging (usually more then one) involved in
every project I do, thus there is always a switch and (sometimes) this
switch is flipped at run-time. Sometimes there is also a
Null_Destination.

But developing this logging theme let's consider a real (my) life
example.  You receive the events for logging but you don't want
5,000,000 records of the same to go in when some device malfunctions.
You rather want first 10, and something stating that this is serious
condition, etc. Is there a way to use stateless adapter or you have to
have a context?

George

>
> I would create the derived (concrete) log that is *empty* and does
> nothing and pass it as Log'Class to wherever it is expected.
> It cannot be simpler than that.
>
> Is it academic? I would do it at the nearest opportunity.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: How to return an empty aggregate

[Maciej Sobczak]

On 6 Kwi, 00:36, george.p...@gmail.com wrote:

> > I would create the derived (concrete) log that is *empty* and does
> > nothing and pass it as Log'Class to wherever it is expected.
> > It cannot be simpler than that.
>
> So you derive concrete from not-empty type?

I derive empty concrete from the interface:

type Log is interface;
procedure Put (L : in Log; S : in String) is abstract;

-- ...

type Null_Log is new Log with null record;
procedure Put (L : in Null_Log; S : in String) is
begin
  -- some pragma here to shut up warnings
  -- about unused parameters
  null;
end Put;

--
Maciej Sobczak *www.msobczak.com*www.inspirel.com

Re: How to return an empty aggregate

[Maciej Sobczak]

On 6 Kwi, 09:00, george.p...@gmail.com wrote:

> You receive the events for logging but you don't want
> 5,000,000 records of the same to go in when some device malfunctions.
> You rather want first 10, and something stating that this is serious
> condition, etc. Is there a way to use stateless adapter or you have to
> have a context?

There is a way to have a filter Log that feeds its selected output
into another Log'Class - and that second Log object can be whatever,
including empty null log.

Hint: essentially you want some Ada equivalent of the following pipe
construct:

$ someprogram | head > somefile.log

which in some particular case might become just:

$ someprogram | head > /dev/null

as opposed to direct:

$ someprogram > somefile.log

or:

$ someprogram > /dev/null

The presence of "head" filter changes nothing in the applicability of /
dev/null - that's why, in Ada terms, it can always have the same
implementation:

type Null_Log is new Log with null record.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: How to return an empty aggregate

[george.priv]

On Apr 6, 4:04 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 6 Kwi, 09:00, george.p...@gmail.com wrote:
>
> > You receive the events for logging but you don't want
> > 5,000,000 records of the same to go in when some device malfunctions.
> > You rather want first 10, and something stating that this is serious
> > condition, etc. Is there a way to use stateless adapter or you have to
> > have a context?
>
> There is a way to have a filter Log that feeds its selected output
> into another Log'Class - and that second Log object can be whatever,
> including empty null log.
>
> Hint: essentially you want some Ada equivalent of the following pipe
> construct:
>
> $ someprogram | head > somefile.log
>
> which in some particular case might become just:
>
> $ someprogram | head > /dev/null
>
> as opposed to direct:
>
> $ someprogram > somefile.log
>
> or:
>
> $ someprogram > /dev/null
>
> The presence of "head" filter changes nothing in the applicability of /
> dev/null - that's why, in Ada terms, it can always have the same
> implementation:
>
> type Null_Log is new Log with null record.
>
> --
> Maciej Sobczak *www.msobczak.com*www.inspirel.com

I think you misunderstand.  I am not questioning value of the concept
of adapter in general.  My point was that value of adapter (strategy
if you wish) with no context is approaching 0 and my example was to
demonstrate precisely that point.

G.