Thinking more on it, I probably under represented the cons for #2.
They are all related but just to be complete:
1. Cannot be used in a lot Gnoga API calls due to not extending any Gnoga
types
2. Doesn't follow the standard Gnoga creation patterns (the Con I
mentioned ealier)
3. Unable to set it as Dynamic and have another Gnoga component manage
deleting
pointers to it. So you have to manually manage memory with it (or use a
smart access
container type).
There may be others that I am not considering.
That said, I still prefer #2 over #1. I am mostly presenting #1 because it
looks and acts
more like a Gnoga type and I know some people might prefer that.
On Fri, Jun 2, 2017 at 11:51 AM, Jeffrey R. Carter <jrcar...@acm.org> wrote:
> On 06/02/2017 02:44 AM, Jeremiah Breeden wrote:
> > So an update. I have two different implementations. They each have
> pros and
> > cons and wanted to get feedback on which one would be better to submit.
> I can
> > submit both if desired
>
> I prefer Version 2. Version 1 has too many cons; Version 2 only has 1.
>
> --
> Jeff Carter
> "When and now is this guitar piece from Stottlemeyer?
> Yes, it's with Mr. Dog in Gertrude's pinball forest."
> The World's Funniest Joke
> 133
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
