Creating instances of actions, attributes and classes and attaching it to a domain don't necessarily use' the action (java warnings thrown) about burlap HOT 9 CLOSED

And by small, I mean, in the grand scheme of things I can work around this. However, I realize the change to the code could be large.

from burlap.

This is a coding philosophy where I kind of diverge from java-proper. The approach that is implemented now is by design because it saves you writing extra lines of code (one of my pet-peeves with java is that it is very verbose; cf. our discussion on exceptions), but it is true that java doesn't "like" it and it is true that it's not quite as transparent as requiring the client to directly link it. For those reasons, it's something that I strongly debated when I originally implemented it that way. My preference is how it is now, but since the goal is for BURLAP to be used by the public, it may be better to conform with how the majority would prefer it to be. I think right now I'd like to leave this as is until more people comment and if most people think it should be switched we can go with that.

from burlap.

@brawner's suggestion is definitely more in line with Java convention. The verbosity issue is why I typically prefer Scala or Jython wherever I have a choice. Convenience APIs for bulk-adds might help though.

from burlap.

If fewer lines of code is what you are looking for... you don't have to use carriage returns :)

If you want more concise code, you can always overload the methods in the domain class like this.

public Domain generateDomain() {
    Domain domain = new SADomain();
    domain.addNewAttribute("attribute1", Attribute.AttributeType.DISC);
    domain.addNewAttribute("attribute2", Attribute.AttributeType.DISC);
    domain.addNewObjectClass("objectClass", new String[] {"attribute1", "attribute2"});
}

But this adds a lot of code to burlap to reduce the client side by an insignificant amount of code.

Still, it's a large job. I suggest it stays as an enhancement request until someone wants to refactor and create version that's not backwards compatible.

from burlap.

That could possibly work, although the reason that I'm slightly hesitant toward it is that I like constructing outside because if for some reason someone wanted to subclass an action or attribute to add some non-standard functionality, they could. Maybe there could be other methods to link the "old" way (or that is, methods on the domain class to add an ObjectClass instance, rather than requesting it to be made) too though getting the best of both words.

I agree that this issue should be left open as an enhancement request.

from burlap.

You know, I was thinking about this a bit more and I wonder if it ultimately ends up being a non-issue. That is, the way BURLAP currently works is that in the attribute/object class/etc. constructor, it makes a call to the domain's addAttribute (et al.) method to add itself to the domain. Subsequent calls to the domain add method may be made with the same attribute/etc. and the BURLAP domain will not add the object if it already has an attribute/etc. with the same name. This means that in the client code, you could do something like:

Domain domain = new SADomain();
domain.addAttribute(new Attribute(domain, "anAtt", Attribute.AttributeType.INT));

and even though this will implicitly result in two calls to the domain's add attribute method, the attribute would still only be added once and java wouldn't throw any warnings.

from burlap.

I suppose that's ok, as long as that's a supported feature.

On Fri, Mar 14, 2014 at 7:59 PM, jmacglashan [email protected]:

You know, I was thinking about this a bit more and I wonder if it
ultimately ends up being a non-issue. That is, the way BURLAP currently
works is that in the attribute/object class/etc. constructor, it makes a
call to the domain's addAttribute (et al.) method to add itself to the
domain. Subsequent calls to the domain add method may be made with the same
attribute/etc. and the BURLAP domain will not add the object if it already
has an attribute/etc. with the same name. This means that in the client
code, you could do something like:

Domain domain = new SADomain();domain.addAttribute(new Attribute(domain, "anAtt", Attribute.AttributeType.INT));

and even though this will implicitly result in two calls to the domain's
add attribute method, the attribute would still only be added once and java
wouldn't throw any warnings.

Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-37708950
.

from burlap.

Yep, that safe check to prevent adding when it's already there has actually been there since the origin of BURLAP, but for whatever reason I didn't consider that the client could just do it too without breaking the code as a result of that.

I should probably update the domain code in BURLAP accordingly so it stops throwing warnings.

from burlap.

Since I updated all the code so that it didn't produce warnings related to this, I'm going to close this.

from burlap.