Re: Preventing private procedure visibility being made public through extension

[Jere <jhb.chat@gmail.com>]

On Monday, May 22, 2017 at 5:24:11 PM UTC-4, Jeffrey R. Carter wrote:
> On 05/22/2017 12:46 AM, Jere wrote:
> > with Gnoga.Gui.Window;
> > with Gnoga.Gui.View;
> > package Gnoga.Gui.Modal_Dialog is
> >
> >    type Dialog_Type is tagged limited private;
> >    type Dialog_Access is access all Dialog_Type;
> >    type Pointer_To_Dialog_Class is access all Dialog_Type'Class;
> >
> >    procedure Create
> >       (Dialog : in out Dialog_Type;
> >        Parent : in out Gnoga.Gui.Window.Window_Type'Class;
> >        ID     : in     String := "");
> >
> > private
> >
> >    type Dialog_Type is new Gnoga.Gui.View.View_Type with record
> >       Main_View : Gnoga.Gui.View.View_Access := null;
> >    end record;
> >
> > end Gnoga.Gui.Modal_Dialog;
> 
> I don't see any reason for the access type in the full view. It could probably 
> just be View_Type, but I think it should really be 
> Gnoga.Gui.Element.Form.Form_Type, as I'll explain later.
In my original attempt, I ended up passing back an access
value via a function.  In order to avoid having to pass
an Unchecked_Access from an aliased parameter, I went
full access type under the hood.  Based on your later example,
I scrapped that.


> 
> > The other option I was tossing around was to
> > instead add a
> >
> > procedure Add_Component
> >    (Dialog : in out Dialog_Type;
> >     Object : in out Gnoga.Gui.Base.Basetype'Class);
> 
> Mostly what people need in such a dialog are buttons and text widgets 
> (Text_Type). The former are from Gnoga.Gui.Element.Common and the latter from 
> Gnoga.Gui.Element.Form, which is why I think your inner view should be a form. 
> You can create buttons with a form as the parent, but you can't create a text 
> widget without a form. (This seems wrong to me, but that's how Gnoga is. I've 
> often used form widgets but never needed the form functionality.) So as a first 
> cut you could only have
> 
> procedure Create_Button (Button  : in out Button_Type;
>                           Content : in     String := "";
>                           ID      : in     String := "");
> 
> procedure Create_Text (Text  : in out Text_Type;
>                         Size  : in     Positive := 20;
>                         Value : in     String   := "";
>                         Name  : in     String   := "";
>                         ID    : in     String   := "";
>                         Label : in     String   := "");
> 
> and you'd probably cover 95% of uses. Internally, you'd call Button.Create with 
> your form as Parent, and Text.Create with your form as Form. Your client can 
> then attach an on-click handler to the buttons and call Value for the text 
> widgets. If Label is not null, you would create a label to go with Text with 
> Label as its Content.
> 
> You might also want to provide a Create_Div that the client could put a bunch of 
> text into, and a New_Line for putting things on different lines. So you could 
> have dialogs like
> 
> <snipped>
>
> So you'd have to write a number of these Create operations, but there wouldn't 
> be too many of them. I'd want to limit what kinds of things a client can put in 
> a dialog, and maybe how many of them, too.
I get that, and I like the idea.  I'm not sure I agree with the
limitations suggested.  I don't see why doing what you suggest
for just a view type wouldn't cover all cases and still limit
access to the internals of the tagged type.  I ended up
thinking on this and playing around with it.  I scrapped the
internal access type, and I then added a new procedure:

procedure Create_Main_View
  (Dialog : in out Dialog_Type;
   View   : in out Gnoga.Gui.View.View_Type:
   ID     : in     String := "");

That way, they can setup whatever view with
whatever components they want and my Dialog_Type
just supplies the Modal operations to use it.
If they have a new custom type already defined,
then they can just create an intermediate view
to hold it and pass that in.  I'm still playing
with it as my kids allow me time, but so far
it has most of my bases covered.  I think
my only snag so far has to do with the
mechanics of width and height parameters.
I'll probably fire up a question in the gnoga
list for that since it is more HTML/Gnoga
based in nature.  I know it isn't exactly
what you suggested, but hopefully it is 
still a good way to go.  I don't want to
fully limit what types can be used in the
dialog because someone might want to do
something complex like a portable file
chooser dialog (for standalone apps).
In cases like those, I would want to be
able to at least help support custom
widget types.  Maybe I am overthinking it
though.

> 
> But probably if you use Gnoga.Gui.Plugin.jQueryUI.Widget.Dialog_Type with Modal 
> => True you can save yourself the effort.

I didn't realize they had added that.  I'll play with it some to 
see how it works out.  I'm still playing with my handmade one
if only to learn more, but this is a good point and I should
experiment with the jquery one.