[DGD] Fatal error when no user object returned

[Raymond Jennings]

On Wed, Jun 6, 2018 at 4:42 PM, Blain <blain20 at gmail.com> wrote:
> I, personally, only questioned if this was the wise way to handle null
> being returned.  I think it's an arbitrary decision by Felix until he
> states otherwise.

That is your opinion, he has his, and since its his project what he says goes.

Arbitrary decisions are just as valid as well thought out ones.

> To me, a null response should just signal a rejection.
> It's not my code.  I'll deal.  But the lib I'm working on is intended to be
> used by people who are, like me, not C/C++ programmers.  We can handle this
> issue. It's not hard. It list raises the complexity a bit,

And doing it your way would increase the complexity of DGD by adding a
special case.  There is a tradeoff here, so I don't really think it's
an arbitrary decision anyway.

Besides, not making LPC handle it on its own would put policy issues
inside DGD itself.  Presently, LPC is required to handle it by
returning an object, yet that object is allowed to behave however it
wants to.

> so I questioned
> if it has a be that way.  Using empty objects which self-destruct don't
> make sense, but it's certainly doable.
> I don't understand how you people
> think, hence the questioning.

Most likely, we come from the point of view that LPC should bear the
complexity burden as much as practically possible, and that includes
keeping special cases out of DGD.

> Be glad that I come from a different
> perspective and can bring diversity to the project.  I've always made my
> driver object return a dust object. I'll also make mention of this in my
> manual docs which will go with my library.
>
> Cheers
>
> On Wed, Jun 6, 2018, 06:59 <bart at wotf.org> wrote:
>
>> On Tue, 5 Jun 2018 20:00:06 -0700, Dread Quixadhal wrote
>> > I guess the question is what role DGD is supposed to perform.
>> >
>> > Is it a mini-operating system or virtual machine, meant for use by
>> > professionals?  Or is it a tool to help people create games and
>> > applications where they might lack the experience or discipline to
>> > simply code them in their native environment, using their native tools?
>>
>> I'd argue there is a lot of grey area between those 2 extremes.
>>
>> >
>> > If the person running any given server is supposed to be a
>> > professional whose skill level is appropriate for running a
>> > professional level service, then an unforgiving adherence to the API
>> > is exactly the correct approach, since they should know better and
>> > shouldn’t touch things the don’t fully understand.
>> >
>> > If, on the other hand, you are trying to attract non-programmers to
>> > the genre and give them a platform to experiment on, a certain
>> > amount of leniency is probably appropriate.
>>
>> First of all, the general thought that a beginners platform should be
>> somewhat
>> nice and forgiving for experimentation sounds good, and I am quite on board
>> with regards to that idea in general. However, DGD on its own is not such a
>> platform for very obvious reasons (it is like a java vm without any kind of
>> jre or a PC with a bios but no OS installed, a tool for which you first
>> need
>> to create an object library which in this case requires skills similar to
>> those needed for writing a small OS). Together with an appropriate object
>> library it can certainly be used for creating such a platform.
>>
>> However, when it comes to breaking the low level api, leniency is not the
>> right approach, it merely means that problems will kinda kinda kinda stay
>> below the surface and this still unexperienced coder will learn habits
>> which
>> are going to hurt. Its much better to learn the right thing the first time
>> around instead of having to relearn what you thought was working perfectly
>> fine many years later, and the more deeply embedded in a system the code in
>> question is, the more important this becomes.
>>
>> DGD with an object library can be a very interesting learning platform, and
>> one that can, depending on the object library, be used by relatively
>> unexperienced coders to create a game or such.
>>
>> But the object library, especially the low level part of it (/kernel) is
>> something you really only should work on when you are a very experienced
>> coder, unless you can deal with breakage and use that for learning. Its not
>> something to attempt on a runtime state that you care about unless you very
>> carefully tested it in some unimportant environment first.
>>
>> You see, there are many ways in which you can simply lock yourself out when
>> messing with low level code, especially when it is connection related code,
>> and hence even very experienced coders should still test any such changes
>> on
>> an unimportant test instance first.
>>
>> Bart
>> --
>> https://www.bartsplace.net/
>> https://wotf.org/
>> https://www.flickr.com/photos/mrobjective/
>>
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd