comp.lang.ada
 help / color / mirror / Atom feed
From: Jere <jhb.chat@gmail.com>
Subject: Re: Private extension of a synchronized interface
Date: Sun, 17 Feb 2019 07:36:18 -0800 (PST)
Date: 2019-02-17T07:36:18-08:00	[thread overview]
Message-ID: <70d5022b-963d-4ee5-b45d-e9c6a28037eb@googlegroups.com> (raw)
In-Reply-To: <q4bsfm$8k3$1@gioia.aioe.org>

On Sunday, February 17, 2019 at 9:52:42 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2019-02-17 14:46, Jere wrote:
> > On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote:
> >>
> >> But synchronized interfaces are totally bogus from the software design
> >> POV. It is a pure implementation aspect exposed. Why do you care?
> >> Aggregate a protected object and delegate primitive operations to it.
> >>
> > 
> > That's what I am doing as my own solution.  I was intrigued with the code
> > above as an alternate solution because it could potentially give a
> > compile time indication that a procedure was a protected operation (as
> > opposed to me relying on simply providing that via comments).
> 
> Given to who? The compiler knows already, the user should not care. It 
> is an implementation aspect which simply does not belong here.
> 
The compiler cannot always tell depending on how and where you call buried
protected operations.  I always prefer compile time catching over run time 
catching.


> > A delegate non protected procedure has to rely on the comment.
> 
> There is no contract that could require it protected. It is a property 
> of the object/task and no property of an operation. You could not do 
> anything with a task or protected object that would not resolve into a 
> protected action anyway.

Protected procedures/functions/entries are particularly heavy operations.
I don't know if you generally work in low level embedded environments, 
but being able know and plan for that can be very critical.  It can
change how you approach your design.  When you work in systems where
your system clock is 1-4MHz, timing of operations does start to matter.

> > However, I honestly
> > wanted to know why Ada allowed one to setup the private extension but not
> > allow you to actually provide the functions (or if this was a GNAT issue or
> > if I was just not using the right syntax).  So the reason I care was a
> > thirst for knowledge of how things work.
> 
> Ada 2005 stuff, most of it makes little sense to me. It was some 
> halfhearted attempt to unite tagged types with tasks and protected 
> objects with no desire to actually do that...
> 
I'm just curious if or why the process was stopped half way instead of
abandoned or completed (again that is assuming I didn't use the wrong
syntax, in which case it's simply that I'm structuring the syntax wrong).

I don't really need to marry them with tagged types.  I do appreciate
the ability to dispatch over a group of related but different tasks
much more easily and the interfaces give that.  The way that Ada chose
to implement interfaces is one of many ways (not all of which would 
have required tagged types).

  reply	other threads:[~2019-02-17 15:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16  0:52 Private extension of a synchronized interface Jere
2019-02-17  9:50 ` Dmitry A. Kazakov
2019-02-17 13:46   ` Jere
2019-02-17 14:52     ` Dmitry A. Kazakov
2019-02-17 15:36       ` Jere [this message]
2019-02-17 16:28         ` Dmitry A. Kazakov
2019-02-17 20:56           ` Jere
2019-02-17 22:36 ` Simon Wright
2019-02-18  0:36   ` Jere
2019-02-18  8:11     ` Dmitry A. Kazakov
2019-02-18  8:29       ` Simon Wright
2019-02-18  8:42         ` Dmitry A. Kazakov
2019-02-18  8:26     ` Simon Wright
2019-02-18  8:33     ` Simon Wright
2019-02-18 15:40       ` Jere
2019-02-18 17:24         ` Simon Wright
2019-02-19 11:04           ` Simon Wright
2019-02-20  2:36             ` Jere
2019-02-20 10:46               ` Simon Wright
2019-02-20 15:04                 ` Jere
2019-02-18 15:49       ` Jere
2019-02-18 22:06 ` Randy Brukardt
2019-02-18 22:35 ` Randy Brukardt
2019-02-19 10:01   ` Egil H H
2019-02-19 11:29     ` Simon Wright
2019-02-19 11:53       ` Egil H H
2019-02-20  2:32   ` Jere
2019-02-20 13:46   ` Simon Wright
2019-02-20 23:43     ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox