* How to return an empty aggregate @ 2008-04-01 11:58 Maciej Sobczak 2008-04-01 12:54 ` Anh Vo ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Maciej Sobczak @ 2008-04-01 11:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 11:58 How to return an empty aggregate Maciej Sobczak @ 2008-04-01 12:54 ` Anh Vo 2008-04-01 17:18 ` Adam Beneschan 2008-04-01 13:34 ` Dmitry A. Kazakov 2008-04-01 15:00 ` Robert A Duff 2 siblings, 1 reply; 20+ messages in thread From: Anh Vo @ 2008-04-01 12:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 12:54 ` Anh Vo @ 2008-04-01 17:18 ` Adam Beneschan 2008-04-02 7:16 ` Maciej Sobczak 0 siblings, 1 reply; 20+ messages in thread From: Adam Beneschan @ 2008-04-01 17:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 17:18 ` Adam Beneschan @ 2008-04-02 7:16 ` Maciej Sobczak 0 siblings, 0 replies; 20+ messages in thread From: Maciej Sobczak @ 2008-04-02 7:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 11:58 How to return an empty aggregate Maciej Sobczak 2008-04-01 12:54 ` Anh Vo @ 2008-04-01 13:34 ` Dmitry A. Kazakov 2008-04-01 15:00 ` Robert A Duff 2 siblings, 0 replies; 20+ messages in thread From: Dmitry A. Kazakov @ 2008-04-01 13:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 11:58 How to return an empty aggregate Maciej Sobczak 2008-04-01 12:54 ` Anh Vo 2008-04-01 13:34 ` Dmitry A. Kazakov @ 2008-04-01 15:00 ` Robert A Duff 2008-04-02 7:19 ` Maciej Sobczak 2 siblings, 1 reply; 20+ messages in thread From: Robert A Duff @ 2008-04-01 15:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-01 15:00 ` Robert A Duff @ 2008-04-02 7:19 ` Maciej Sobczak 2008-04-03 5:02 ` george.priv 0 siblings, 1 reply; 20+ messages in thread From: Maciej Sobczak @ 2008-04-02 7:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-02 7:19 ` Maciej Sobczak @ 2008-04-03 5:02 ` george.priv 2008-04-03 9:09 ` Maciej Sobczak 0 siblings, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-03 5:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-03 5:02 ` george.priv @ 2008-04-03 9:09 ` Maciej Sobczak 2008-04-04 15:38 ` george.priv 0 siblings, 1 reply; 20+ messages in thread From: Maciej Sobczak @ 2008-04-03 9:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-03 9:09 ` Maciej Sobczak @ 2008-04-04 15:38 ` george.priv 2008-04-04 20:35 ` Maciej Sobczak 0 siblings, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-04 15:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-04 15:38 ` george.priv @ 2008-04-04 20:35 ` Maciej Sobczak 2008-04-04 23:58 ` george.priv 0 siblings, 1 reply; 20+ messages in thread From: Maciej Sobczak @ 2008-04-04 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-04 20:35 ` Maciej Sobczak @ 2008-04-04 23:58 ` george.priv 2008-04-05 13:48 ` Maciej Sobczak 0 siblings, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-04 23:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-04 23:58 ` george.priv @ 2008-04-05 13:48 ` Maciej Sobczak 2008-04-05 16:04 ` george.priv 0 siblings, 1 reply; 20+ messages in thread From: Maciej Sobczak @ 2008-04-05 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-05 13:48 ` Maciej Sobczak @ 2008-04-05 16:04 ` george.priv 2008-04-05 21:14 ` Maciej Sobczak 0 siblings, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-05 16:04 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-05 16:04 ` george.priv @ 2008-04-05 21:14 ` Maciej Sobczak 2008-04-05 22:36 ` george.priv 2008-04-06 7:00 ` george.priv 0 siblings, 2 replies; 20+ messages in thread From: Maciej Sobczak @ 2008-04-05 21:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-05 21:14 ` Maciej Sobczak @ 2008-04-05 22:36 ` george.priv 2008-04-06 19:53 ` Maciej Sobczak 2008-04-06 7:00 ` george.priv 1 sibling, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-05 22:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-05 22:36 ` george.priv @ 2008-04-06 19:53 ` Maciej Sobczak 0 siblings, 0 replies; 20+ messages in thread From: Maciej Sobczak @ 2008-04-06 19:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-05 21:14 ` Maciej Sobczak 2008-04-05 22:36 ` george.priv @ 2008-04-06 7:00 ` george.priv 2008-04-06 20:04 ` Maciej Sobczak 1 sibling, 1 reply; 20+ messages in thread From: george.priv @ 2008-04-06 7:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-06 7:00 ` george.priv @ 2008-04-06 20:04 ` Maciej Sobczak 2008-04-07 20:23 ` george.priv 0 siblings, 1 reply; 20+ messages in thread From: Maciej Sobczak @ 2008-04-06 20:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: How to return an empty aggregate 2008-04-06 20:04 ` Maciej Sobczak @ 2008-04-07 20:23 ` george.priv 0 siblings, 0 replies; 20+ messages in thread From: george.priv @ 2008-04-07 20:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-04-07 20:23 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-01 11:58 How to return an empty aggregate Maciej Sobczak 2008-04-01 12:54 ` Anh Vo 2008-04-01 17:18 ` Adam Beneschan 2008-04-02 7:16 ` Maciej Sobczak 2008-04-01 13:34 ` Dmitry A. Kazakov 2008-04-01 15:00 ` Robert A Duff 2008-04-02 7:19 ` Maciej Sobczak 2008-04-03 5:02 ` george.priv 2008-04-03 9:09 ` Maciej Sobczak 2008-04-04 15:38 ` george.priv 2008-04-04 20:35 ` Maciej Sobczak 2008-04-04 23:58 ` george.priv 2008-04-05 13:48 ` Maciej Sobczak 2008-04-05 16:04 ` george.priv 2008-04-05 21:14 ` Maciej Sobczak 2008-04-05 22:36 ` george.priv 2008-04-06 19:53 ` Maciej Sobczak 2008-04-06 7:00 ` george.priv 2008-04-06 20:04 ` Maciej Sobczak 2008-04-07 20:23 ` george.priv
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox