Asciidoctor :: Discussion - Re: Asciidoctor 0.1.3 attributes and conflict with AJI

Re: Asciidoctor 0.1.3 attributes and conflict with AJI

Posted by mojavelinux on Jun 04, 2013; 9:13am
URL: https://discuss.asciidoctor.org/Asciidoctor-0-1-3-attributes-and-conflict-with-AJI-tp258p270.html

Alex,

Thanks for bringing this to my attention. I didn't realize the type check on the attributes option would end up being too restrictive when integrating with Java. Shoot. I'll have to remember to be careful when dealing with data types that are passed in and out of the Asciidoctor APIs.

I was curious what ancestors the Map has when it comes from Java, so I did a little bit of digging. Here's the ancestor collection that is reported:

[Java::JavaUtil::HashMap, Java::JavaLang::Cloneable, Java::JavaIo::Serializable, Java::JavaUtil::AbstractMap, Java::JavaUtil::Map, Enumerable, Java::JavaLang::Object, ConcreteJavaProxy, JavaProxy, JavaProxyMethods, Object, Kernel, BasicObject]

Looking through there, I see that we have Enumerable, but we don't have Hash. The closest type, as you pointed out, is Java::JavaUtil::Map. I filed an issue to support this type if the engine is JRuby.

https://github.com/asciidoctor/asciidoctor/issues/396

I've fixed it with this pull request:

https://github.com/asciidoctor/asciidoctor/pull/397

The key line that I changed was:

if attrs.is_a?(Hash) || (RUBY_ENGINE == 'jruby' && attrs.is_a?(Java::JavaUtil::Map))

To make the API as flexible as possible, I added a fallback for anything that is Hash like (responds to both "keys" and "[]") and convert it to a Hash. That way, we should be safe if someone passes in a custom dictionary and expects it to work.

You should be able to remove your workaround in 0.1.4.

Cheers,

-Dan

On Sat, Jun 1, 2013 at 5:58 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

Well in fact RubyHash implements Map so no problem in that way but because Option class is a model class which could be used when we integrate AJI with Javascript (if we find useful of course) I would like to maintain Option class free of JRuby dependencies

El diumenge 2 de juny de 2013, lightguard.jp [via Asciidoctor :: Discussion] ha escrit:

Another possibility is to create our own implementation of a map that also implements the RubyHash interface as well, no reason we couldn't do that.
—
Sent from Mailbox for iPhone

On Sat, Jun 1, 2013 at 4:30 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:

well it is clean, the problem is that you iterate through a Map for moving all elements from one kind of map to another kind of map, so it is a problem of performance more than something that it cannot be understood. Also I must admit that when I have seen all my tests failing I have entered on panic time and for this reason I have written a post on this forum, but the solution of the problem is easy to understand.

Tomorrow I will release the 0.1.3 version, so Maven, Gradle, Asciidoclet, Viewers, ... can upgrade.

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-0-1-3-attributes-and-conflict-with-AJI-tp258p261.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Asciidoctor-0-1-3-attributes-and-conflict-with-AJI-tp258p262.html

To unsubscribe from Asciidoctor 0.1.3 attributes and conflict with AJI, click here.
NAML

--
Enviat amb Gmail Mobile

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Asciidoctor-0-1-3-attributes-and-conflict-with-AJI-tp258p263.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

Dan Allen | http://google.com/profiles/dan.j.allen