Like the one I was talking about - should never have mentioned package managers :-X
Absolutely agree, both on the general Mac dislike and on application bundles. But then, I grew up with RiscOS, which did this really neatly years ago. In fact, a lot of good things on Mac were in RiscOS years ago!
On a slightly related note, and as I posted in the JamVM thread, I noticed in an article the other week that Cyberduck is in the Mac App Store - interesting because it bundles a JVM in a nice self-contained bundle!
Packages are handy for dependencies, but it doesn’t make sense for most games, and especially java games. I suppose the dependency on java itself is one, but java is something a lot of distributions have f***ed up in such epic fashion that I don’t install it through the package manager either.
[quote=“princec,post:209,topic:37519”]
Synth? Does it include basic drum effects implemented in a small enough amount of code that it might fit into a 4k game?
Software engineering should be in a completely different curriculum. Except it probably shouldn’t be called “engineering” either. As unsexy as it sounds, “Computer Programming” really does sum it up.
… says the guy whose job title is “Software Engineer”. :persecutioncomplex:
No doubt… One can’t work that long in the industry and not grok that… ;D
Then don’t criticize those looking towards entity systems and by general extension component architectures as wasting time or that they suck as the handful of us that are doing this are searching and some of us have found what we consider a better way. Searching and experimenting takes time and most definitely it takes an immense amount of time to convert a significant existing OO framework to a very granular component oriented one. I only did so after I saw the writing on the wall and pushed the older way to the limits. The inflexibility that you speak of above was obvious in my efforts with traditional Java / OOP mechanisms and I tried everything before going whole hog toward component architectures. Almost everything in my efforts now can be replaced or substituted fairly easily from external configuration files. A great deal of time was spent minimizing dependencies between components and related groupings so this is possible.
Beside the scenario above as you describe is just a poor API / framework that didn’t do what it is intended to accomplish and I believe someone above commented on this sentiment in a reply above. I’m aware there may be times when a dev desires to mod a perfectly working API to do something slightly different as well, but usually that is an exceptional case as OOP in itself doesn’t disable extension.
It can be, but I’m not ready to give up on Java yet. Though I certainly keep in mind how the CA can be leveraged from Scala and other JVM languages. In fact I certainly posit that it’s a much better way to integrate Java w/ Scala or other JVM languages as opposed to extension of Java classes. I still need to experimentally validate this, but I put a lot of thought into it. A simple shift in perspective and coding practice is what I’m really trying to get at and while it works for me it may not work for everyone. The only downside so far is increased verbosity at the Java layer. There should be some ways with Scala for instance to reduce the verbosity in practice.
Now, I’m certainly not saying anyone has to follow me down the path I’m heading, but I do believe it will benefit any project small to large. It’s not “f**king insane” as a poster above claimed. I have a large body of code that has only seen a benefit and things still chug along nicely in a reasonably complex 3D demo case. There will be early adopters and the typical bell curve of adoption. I most definitely have an up hill battle to fight, but it’s an pedagogical one that can be overcome with good documentation, lots of clear tutorials, and perhaps a hit app or game + outside success stories. All that takes time…
To continue I would posit further that yet again this is a dirty mark on OOP and the is-a and explicit has-a relationship. It doesn’t lend to flexible APIs / frameworks that can be easily extended or reconfigured and only truly works well for small to mid (at the most) sized projects in terms of maintenance unless there is someone full time working as a “cleaner / hands on architect” that can see the forest from the trees and has authority to refactor and uphold whatever standards that are set up. Code reviews are not enough in this regard as it’s really an active full time position for a larger project with one or more folks involved day to day. Most small to mid sized projects with various devs involved benefit from a dedicated hands on architect.
Again a clarification, in my experience standard OOP as implemented in status quo Java projects doesn’t work well as the central organizing mechanism, but is less of a deadly force in the leaves of any API / framework. Thus while my new efforts are component oriented they are partially still OO in the leaves which means some of the components / systems themselves. As a framework dev it’s impossible to limit OOP in the leaves since OO is baked into Java. This is not necessarily the case for the entity system where it is recommended to minimize OO in the leaves, but for the runtime layer of my efforts it makes sense where there are component peers w/ a base cross-platform implementation + J2SE and Android peer extensions. Mind you the interface based programming aspect comes in because one stores the given platform implementation by the common interface / contract in the CA thus on any platform the dev just retrieves the particular platform implementation component by its common interface and bam easy cross-platform support w/ ease of adding more platform support on an as needed basis.
A simple shift of perspective to promoting the implicit has-a relationship as foundational and minimizing the explicit form and is-a relationship is not crazy. It’s just a different approach. This is also fairly “CS 103” material and shouldn’t be strange language per se. It is a shift of perspective nonetheless though. It’s true power is not realized until a significant amount of code is converted to this mechanism.
I know the “AbstractComponentManagerControl” thing may be hard to follow from a previous post as that is an implementation detail specific to my efforts, but I’ll show it in psuedocode below (just a snippet mind you and not using best practices / IE never use foreach loop in near realtime bound code). It basically is an internally used component that can extend and change the behavior of the manager itself. It is what allows vetoing and encapsulation back that otherwise would be lost by the implicit has-a relationship. If you wanted to make a particular compound component final you’d first composite all the desired included components then add an ACMC that vetoes further set / unset actions.
This code is not the exciting part per se, but defines the bread and butter implicit has-a relationship. The exciting part is building a larger framework around a few essential new patterns that come from all of this.
public class ComponentManager
{
HashMap<Class<IComponent>, IComponent> components
HashMap<Class<IComponent>, Collection<IComponent>> componentCollections
public <C extends IComponent> C getAs(Class<C> componentType)
{
return components != null ? components.get(componentType) : null;
}
public <C extends IComponent> Collection<C> getCollection(Class<C> componentType)
{
return componentCollections != null ? componentCollections.get(componentType) : null;
}
// Sets a component adding it to this component manager
public <C extends IComponent> boolean set(Class<C> componentType, C component)
{
Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
AbstractComponentManagerControl.class);
if (controlCollection != null)
{
// Iterate through ACMCs to perform extra control actions or potentially veto set altogether if a control returns true.
for (AbstractComponentManagerControl control : controlCollection)
{
if (control.set(this, componentType, component)
{
// control vetoed set action
return false;
}
}
}
return components.put(componentType, component);
}
public <C extends IComponent> IComponent unset(Class<C> componentType)
{
Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
AbstractComponentManagerControl.class);
if (controlCollection != null)
{
// Iterate through ACMCs to perform extra control actions or potentially veto unset altogether if a control returns true
for (AbstractComponentManagerControl control : controlCollection)
{
if (control.unset(this, componentType)
{
// control vetoed unset action
return null;
}
}
}
return components.remove(componentType);
}
}
I was being a little rhetorical in that statement. It’s fundamental knowledge essentially and is widely recognized as a best practice in the industry.
On whether software engineering is a separate discipline I at least do not treat it as such. The left hand must know what the right hand is doing otherwise if you just want to be a brick layer and be paid less be a programmer with little responsibility. You may eventually despise your work / job when non-software engineers / architects are calling the shots and this will happen at some point if you don’t demand to take control of this or keep it in mind in your career path. Besides when working as an indie one does both. There is no reason why one can’t be a hands on architect especially on a small to mid sized team.
As far as teaching and degree wise I absolutely think it’s a tragedy that things are being separated. After the CS 101/102/103 but before the typical data structures / algorithms course software architecture / engineering should be part of the curriculum. What are data structures other than patterns of organizing data. This is accomplished through a knowledge of the “paradigm” of implementation OO or otherwise. A course on design patterns before data structures seems appropriate in my opinion.
material and shouldn’t be strange language per se. It is a shift of perspective nonetheless though. It’s true power is not realized until a significant amount of code is converted to this mechanism.