[DGD] Fatal error when no user object returned
Blain
blain20 at gmail.com
Thu Jun 7 01:42:04 CEST 2018
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. 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, 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. 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
More information about the DGD
mailing list