Skip to content

Jerry API update #1177

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

Merged
merged 1 commit into from
Jul 11, 2016
Merged

Conversation

LaszloLango
Copy link
Contributor

No description provided.

@LaszloLango LaszloLango added enhancement An improvement api Related to the public API labels Jun 30, 2016
@LaszloLango LaszloLango added this to the Release v1.0 milestone Jun 30, 2016
@@ -2265,24 +2264,22 @@ parser_parse_script (const jerry_char_t *source_p, /**< source code */
* Note:
* returned error object should be freed with jerry_release_object
*/
jsp_status_t
parser_parse_eval (const jerry_char_t *source_p, /**< source code */
ecma_object_t *
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer return with an ecma_value_t.

@zherczeg
Copy link
Member

@poussa and @lemmaa the API update patch is here. Could you give your feedback about the changes in jerry-api.h? Of course you can give feedback for other files as well but since you use the api, we would value your opinion about the API itself.

const jerry_value_t);

jerry_value_t jerry_function_call (const jerry_value_t, const jerry_value_t, const jerry_value_t[], jerry_size_t);
jerry_value_t jerry_object_construct (const jerry_value_t, const jerry_value_t[], jerry_size_t);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use function_call and construct_object

@poussa
Copy link
Contributor

poussa commented Jun 30, 2016

@jimmy-huang @grgustaf FYI changes coming. PTAL.

@tilmannOSG
Copy link

@franc0is @HBehrens We would appreciate your feeback on the new API as well :)

@grgustaf
Copy link
Contributor

grgustaf commented Jul 1, 2016

One of @zherczeg 's comments above reminded me, it seems odd that jerry_get_array_length returns uint32_t but [gs]et_array_index_value take jerry_length_t. But I'll admit the myriad aliases for ints confuse me.

Is that as it should be?


/**
* General API functions of JS objects
*/
bool jerry_is_array (const jerry_object_t *);
bool jerry_is_constructor (const jerry_object_t *);
bool jerry_is_function (const jerry_object_t *);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we removing these 3 jerry_is_* functions? How to use the new API to achieve the same functionality?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are new functions ofr that:

bool jerry_value_is_array (const jerry_value_t);

the point is we don't export the real types of values anymore, all of them are jerry_value_t


/**
* Get the global context
*/
jerry_object_t *jerry_get_global (void);
jerry_value_t jerry_get_global (void);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use jerry_get_global_object since it is not clear that global is an object anymore.

prop_desc_p->is_set_defined = prop_desc.is_set_defined;
prop_desc_p->is_value_defined = prop_desc.is_value_defined;

prop_desc_p->getter = ecma_make_object_value (prop_desc.get_p);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is_getter defined? NULL check?


Pointers to strings or objects and values should be released just when become unnecessary, using `jerry_release_string` or `jerry_release_object` and `jerry_release_value`, correspondingly.
JerryScript value can be a boolean, number, null, object, string or undefined. The value has an error flag,
that indicates whether is an error or not. Every type can be an error not only objects.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every type has an error flag not only objects.

@zherczeg
Copy link
Member

zherczeg commented Jul 8, 2016

I think this is a great job!
LGTM after fixing those small issues.

@LaszloLango LaszloLango force-pushed the jerry-api-dev branch 2 times, most recently from 79a7a19 to 67147cb Compare July 8, 2016 12:50
@LaszloLango
Copy link
Contributor Author

@zherczeg, @dbatyai, I've updated the PR. Please check


Pointers to strings or objects and values should be released just when become unnecessary, using `jerry_release_string` or `jerry_release_object` and `jerry_release_value`, correspondingly.
JerryScript value can be a boolean, number, null, object, string or undefined. The value has an error flag,
that indicates whether is an error or not. Every type has an error flag not only objects.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should also be noted that the error flag should be cleared before the value is passed as an argument.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And that created error objects automatically have the flag set.

@dbatyai
Copy link
Member

dbatyai commented Jul 8, 2016

LGTM otherwise.

* Removed jerry_string_t and jerry_object_t
* Updated function names
* Updated return values
* Updated function descriptions
* Added new functions
* Added new unittests

JerryScript-DCO-1.0-Signed-off-by: László Langó [email protected]
@LaszloLango LaszloLango merged commit 9bce5b0 into jerryscript-project:master Jul 11, 2016
@jiangzidong
Copy link
Contributor

@LaszloLango Hi, can I assume that it is the API 1.0, and will not change a lot in this period?

@zherczeg
Copy link
Member

We are hoping this API will be stable. Perhaps we add more functions, but not removing them. Unless something serious comes up. Hopefully not.

@jiangzidong
Copy link
Contributor

Thanks! and is our next step is Jerry Port API #964?:)

@LaszloLango
Copy link
Contributor Author

@jiangzidong, yes. Port API patch will be the next :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Related to the public API enhancement An improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants