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

Closed
rjnienaber opened this issue Dec 30, 2014 · 0 comments
Closed

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

rjnienaber opened this issue Dec 30, 2014 · 0 comments

Comments

@rjnienaber
Copy link

@rjnienaber rjnienaber commented Dec 30, 2014

From: http://jira.codehaus.org/browse/JRUBY-6453

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.createASCIIString(byte[]);
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 #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 #1 until there is something).
@rjnienaber rjnienaber closed this Jun 24, 2019
@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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants