* Intermixing two tagged types @ 2014-08-13 20:32 Victor Porton 2014-08-14 7:58 ` Simon Wright 0 siblings, 1 reply; 7+ messages in thread From: Victor Porton @ 2014-08-13 20:32 UTC (permalink / raw) I am implementing thick Ada2012 bindings for http://librdf.org/raptor/api/raptor2-section-xml-namespace.html This documentation defines two types: raptor_namespace and raptor_namespace_stack. Methods for these types are essentially C functions whose name start with raptor_namespace_ raptor_namespaces_ correspondingly. Now to the trouble (or rather a problem): Some of these functions accept only one the two types: raptor_namespace or raptor_namespace_stack. But there are functions (let's call them "suspicious functions") which accept both raptor_namespace or raptor_namespace_stack types as its arguments. To make things worse, some of suspicious functions have raptor_namespace_ and some raptor_namespaces_ prefix. So (now in Ada terms, which I am implementing) a function can belong to two tagged types. How to formalize this in Ada? I see two variants: 1. Put them into two different packages and do "limited with" from each of the two packages to the other one. 2. Make all suspicious functions belonging to one certain Ada package (which of the two?) I could both types into the same package, but this causes troubles described in <Trouble with "operation can be dispatching in only one type"> comp.lang.ada topic. Please give a good advise what to do in this situation. -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-13 20:32 Intermixing two tagged types Victor Porton @ 2014-08-14 7:58 ` Simon Wright 2014-08-14 11:57 ` Victor Porton 0 siblings, 1 reply; 7+ messages in thread From: Simon Wright @ 2014-08-14 7:58 UTC (permalink / raw) Victor Porton <porton@narod.ru> writes: > So (now in Ada terms, which I am implementing) a function can belong > to two tagged types. Are you sure that it's appropriate to use *tagged* types? And even if if is appropriate for raptor_namespace (i.e., you derive new types from it), is it so for raptor_namespace_stack? - which clearly is a stack of raptor_namespace (or possibly raptor_namespace'Class). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-14 7:58 ` Simon Wright @ 2014-08-14 11:57 ` Victor Porton 2014-08-14 12:06 ` Dmitry A. Kazakov 2014-08-14 16:03 ` Adam Beneschan 0 siblings, 2 replies; 7+ messages in thread From: Victor Porton @ 2014-08-14 11:57 UTC (permalink / raw) Simon Wright wrote: > Victor Porton <porton@narod.ru> writes: > >> So (now in Ada terms, which I am implementing) a function can belong >> to two tagged types. > > Are you sure that it's appropriate to use *tagged* types? And even if if > is appropriate for raptor_namespace (i.e., you derive new types from > it), is it so for raptor_namespace_stack? - which clearly is a stack of > raptor_namespace (or possibly raptor_namespace'Class). Tagged types a little decrease efficiency, but I use tagged types anyway (primarily for controlled finalization). -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-14 11:57 ` Victor Porton @ 2014-08-14 12:06 ` Dmitry A. Kazakov 2014-08-14 16:03 ` Adam Beneschan 1 sibling, 0 replies; 7+ messages in thread From: Dmitry A. Kazakov @ 2014-08-14 12:06 UTC (permalink / raw) On Thu, 14 Aug 2014 14:57:18 +0300, Victor Porton wrote: > Simon Wright wrote: > >> Victor Porton <porton@narod.ru> writes: >> >>> So (now in Ada terms, which I am implementing) a function can belong >>> to two tagged types. >> >> Are you sure that it's appropriate to use *tagged* types? And even if if >> is appropriate for raptor_namespace (i.e., you derive new types from >> it), is it so for raptor_namespace_stack? - which clearly is a stack of >> raptor_namespace (or possibly raptor_namespace'Class). > > Tagged types a little decrease efficiency, There is none, except the place used to keep the type tag. Since non-tagged types do not dispatch, whatever dispatch overhead does not apply. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-14 11:57 ` Victor Porton 2014-08-14 12:06 ` Dmitry A. Kazakov @ 2014-08-14 16:03 ` Adam Beneschan 2014-08-14 16:11 ` Victor Porton 1 sibling, 1 reply; 7+ messages in thread From: Adam Beneschan @ 2014-08-14 16:03 UTC (permalink / raw) On Thursday, August 14, 2014 4:57:18 AM UTC-7, Victor Porton wrote: > Tagged types a little decrease efficiency, but I use tagged types anyway > (primarily for controlled finalization). I haven't been following this discussion carefully enough. So I have no idea whether the following suggestion is appropriate. However ... If you have an untagged record, and it has a component that is a (tagged) controlled type, you'll still get finalization, but using the untagged record as a parameter won't cause any problems with the dispatching rules. Again, I don't know whether this is helpful. I just thought I'd throw it out there in case it is. -- Adam ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-14 16:03 ` Adam Beneschan @ 2014-08-14 16:11 ` Victor Porton 2014-08-14 16:29 ` Adam Beneschan 0 siblings, 1 reply; 7+ messages in thread From: Victor Porton @ 2014-08-14 16:11 UTC (permalink / raw) Adam Beneschan wrote: > On Thursday, August 14, 2014 4:57:18 AM UTC-7, Victor Porton wrote: > >> Tagged types a little decrease efficiency, but I use tagged types anyway >> (primarily for controlled finalization). > > I haven't been following this discussion carefully enough. So I have no > idea whether the following suggestion is appropriate. However ... > > If you have an untagged record, and it has a component that is a (tagged) > controlled type, you'll still get finalization, but using the untagged > record as a parameter won't cause any problems with the dispatching rules. > > Again, I don't know whether this is helpful. I just thought I'd throw it > out there in case it is. Thank you for your suggestion. However I already know this. But working this way would be a wrong way. In the meaning of things the entire record is controlled, not its part. So controlling a part would be a hack, not a good way to do programming. -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Intermixing two tagged types 2014-08-14 16:11 ` Victor Porton @ 2014-08-14 16:29 ` Adam Beneschan 0 siblings, 0 replies; 7+ messages in thread From: Adam Beneschan @ 2014-08-14 16:29 UTC (permalink / raw) On Thursday, August 14, 2014 9:11:02 AM UTC-7, Victor Porton wrote: > Thank you for your suggestion. However I already know this. > > But working this way would be a wrong way. In the meaning of things the > entire record is controlled, not its part. So controlling a part would be a > hack, not a good way to do programming. Unfortunately, sometimes you have make compromises to work around the language. Anyway, if your untagged type has just *one* component that is the "entire" record, that might be close enough to the "right" way to make you feel you're not using a hack--or at least you're using only a minor hack. If you give the component a one-letter name like R, then it means you have to add "R." every time you want to access a field in your record. It's a nuisance. But it might be the least of evils. I've had to do things like this; usually it's when I have a variant record with a discriminant with a default, like: type Value (Value_Type : Value_Classes := Value_Classes'First) is record case Value_Classes is ... end case; end record; (A lot of this was written in the Ada 83 days.) The rules allow you to change the discriminant of a Value by reassigning the whole record. But you *can't* do this if you have an "access Value" Acc; you can't change the discriminant of Acc.all by reassigning it. You *can*, however, wrap Value in another record (with one component V), and if you have an "access Value_Wrapper" Wrapper_Acc, you can change the discriminant of Wrapper_Acc.V.all. Annoying, but it works. There were reasons why this rule is in the language, but I wish it had provided a way to let me allocate a "new Value" whose discriminant can be changed. Providing too many options, however, can muddy the syntax of the language, so it's a trade-off between adding language rules that require annoying workarounds like this, and providing so many features that it drives everybody crazy (language designers, implementors, users) and increases the chance of mistakes or unsafe features creeping into the language semantics. Bottom line is: there is no Holy Grail of a perfect language, and if you wait for a language that never requires you to do things a "wrong" way, you will be waiting a very, very long time. We'll probably solve the halting problem before we can produce a language like that. :) -- Adam ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-08-14 16:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-13 20:32 Intermixing two tagged types Victor Porton 2014-08-14 7:58 ` Simon Wright 2014-08-14 11:57 ` Victor Porton 2014-08-14 12:06 ` Dmitry A. Kazakov 2014-08-14 16:03 ` Adam Beneschan 2014-08-14 16:11 ` Victor Porton 2014-08-14 16:29 ` Adam Beneschan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox