Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make String/ByteList creation facilities part of RedBridge APIs #2397

rjnienaber opened this issue Dec 30, 2014 · 0 comments

Make String/ByteList creation facilities part of RedBridge APIs #2397

rjnienaber opened this issue Dec 30, 2014 · 0 comments


Copy link


In looking at a few native extensions it is clear that we need better facilities for working with Strings and ByteLists (same can maybe be said for IO, but that is a much bigger problem and should be it's own issue).

So far I am not suggesting specific APIs (example below is just illustrative) but we should examine a few common Java native extensions (nokogiri, json, ???) and see how we need to manipulate bytelists and rubystrings and provide something less exposing of internals and brittle.

The one other requirement is that we can make something which works for both 1.8 and 1.9 (and 2.0). If we create two methods where only one requires an encoding we should make it obvious what the difference is:

container.createString(byte[], encoding);

If we had these two forms both just be createString then new developers would probably just use the one without encoding. By providing ASCII in the name it is obvious what decision they are making by calling it.

One last thing. It is clear that we will need to expose access several types of things: Encoding, ByteList, Fixnum? We can cope with this in two ways:

  1. Use Ruby . Ruby exposes way too many things we don't want to encourage.
  2. Add something to ScriptingContainer for getting/creating (probably some contained class: container.getTypeHelper). This has downside of slowly growing to be a huge mess like Ruby I do favor Project suggestions #2 because it will make it very obvious what we intend on supporting. We can also slowly grow it based on user-feedback (hell they can also work-around lack of missing endorsed way by using break script engine #1 until there is something).
@enebo enebo added this to the Invalid or Duplicate milestone Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants