Extending BulkLoader

[janosc...@googlemail.com]

For some special cases my files have to be loaded by a special Loading-
Class. But i want to benefit from the nice features like sequencing
and priority managment from BulkLoader, so the obvious solution is to
extend the BulkLoader-class and to implement an extension point for
external loaders which implement an interface (ILoader or something)
my BulkLoader can communicate with.
The problem is, that most interesting methods and properties in
BulkLoader and LoadingItem are marked as internal, so i cant overide
them from my classes (which are of course in an other package).
So the only solution for the moment is to copy and modify the original
BulkLoader classes, which is not the nice OOP way :(
Why are most properties and methods internal and not protected? Can
you change this?

[Arthur Debert]

Hi Janoschart.

The long story:
Actually I have mixed feelings about this. You see, there'a a lot to
BulkLoader's design that is simply wrong. To make it right, it would
need to be split into many classes, such as classes for constants,
events, each loading item and so on. BulkLoader started very simple
and gotten more and more powerful, but with the burden of complexity.
My design goal was to have an ultra simple package, one class only.
That's why you don't see things such as Types.VIDEO, TYPES.IMAGE and
so on. A lot is bolted into the BulkLoader class, like the name of
events it dispatches. The idea was to keep imports, documentation and
learning curve into a minimum - that is, one class only. In fact the
first draft was just like that, the LoadingItem class wasn't even
public. With time, people needed it to be more flexible, more
powerful, so added features and split the class into other classes.

So the short answer is "you are right". LoadingItem should be some
base class and each loading type should be a more specific
implementation of that. I'd rather use a base class then an
interface, because many housekeeping utilities could be kept on the
base class. But I also feel that having few classes to learn and
understand, no complex code spread among a hierarchy of interfaces,
base classes, factories and what not results in a much simpler use
case. I've seen other loading libraries for as3 that take the design
to death principle, and although correct and well structured, they
feel very clumsy too me.

At first everything was public too. I have a strong bias against
access modifiers: I feel that everything show be public, and
developers should use internal parts on their own risk. But then,
people would read that, for example, the priority property in
LoadingItems was public, change it after the instance was created, and
wonder why the priority queuing didn't change. So in order to avoid
the burden of explaining and documenting all that. So I've left them
as internal, so the package itself would be able to see them, but it
would be off limits for other developers. The end result is exactly
what you are describing: a hard to extend, full of locks structure.
I`ve been juggling these issues a lot on my head and haven't reached a
conclusion. It's very likely that I'll split up LoadingItem into the 5
or 6 classes it needs to be, and by then it will be trivial to extend.

Right now, I wan't to make sure no remaining bugs are left (haha), and
also develop a comprehensive test suite for the library. Once that is
done, I'll probably start some heavy handed refactoring and the issue
you mentioned is probably one of the first targets. I guess I need to
make up my mind to what point it is useful to design and abstract
more, and how that will impact users.

The short story:
A quick hack is to put the extending stuff you need into the same
package. I am curious what are you requirements for extending
LoadingItem ? Maybe it turns out to be useful for more people and we
can merge that in.

This turned out longer than I expected, but I guess I have some more
thinking to do.

Cheers

[janosc...@googlemail.com]

Hello Arthur,
thank you for your reply. I can follow your feelings very well.
But as i see it, changing your internal properties and methods to
protected (not public) wont enable everybody to manipulate variables
or call methods in inappropriate moments, but only those who extend
your classes, and should know what they do.
I like your way of keeping things simple, and as you said there are
enough other overarchitectured loading solutions in as3.

The reason i need to extend your classes is, that i want to support
loading files asynchronously by Flash-Player-extensions like
Northcode, AIR and others. In this case its a question of
configuration which loader should be used, not of bulk-loaders type-
guessing. I dont think bulk-loader should support all, in my opinion
it should support the top10 and enable us to extend it to our very
special requirements. But this is of course your decision.

with best regards,
Janosch

[Arthur Debert]

Hi Janosh.

Just wanted to let you know that, even if it tool me a while, I've
done a large refactor, implemented a reasonable test suite and
organized LoadingItem into various classes, making it much, much
easier to extend.

If you still have the need to do so, please let me know if this helps.

Cheers
Arthur