Add FunctionTemplate::GetClassName to API.

Add FunctionTemplate::GetClassName to API.

The SetClassName is already there, need also the getter.

R=yangguo@chromium.org

[Yang, 2014-07-09 11:41:50]

Looks good, but I'd like Sven's opinion. Also because he's one of the API
gatekeepers.

https://codereview.chromium.org/377213002/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/377213002/diff/1/src/api.cc#newcode1249
src/api.cc:1249: EscapableHandleScope
scope(reinterpret_cast<Isolate*>(isolate));
Not sure whether we really need the handle scope to get rid of just one extra
handle.

[aandrey, 2014-07-09 11:46:24]

https://codereview.chromium.org/377213002/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/377213002/diff/1/src/api.cc#newcode1249
src/api.cc:1249: EscapableHandleScope
scope(reinterpret_cast<Isolate*>(isolate));
On 2014/07/09 11:41:50, Yang wrote:
> Not sure whether we really need the handle scope to get rid of just one extra
> handle.

Removed.

[Yang, 2014-07-10 07:01:55]

On 2014/07/09 11:46:24, aandrey wrote:
> https://codereview.chromium.org/377213002/diff/1/src/api.cc
> File src/api.cc (right):
> 
> https://codereview.chromium.org/377213002/diff/1/src/api.cc#newcode1249
> src/api.cc:1249: EscapableHandleScope
> scope(reinterpret_cast<Isolate*>(isolate));
> On 2014/07/09 11:41:50, Yang wrote:
> > Not sure whether we really need the handle scope to get rid of just one
extra
> > handle.
> 
> Removed.

ping Sven.

[Sven Panne, 2014-07-10 07:53:53]

On 2014/07/10 07:01:55, Yang wrote:
> On 2014/07/09 11:46:24, aandrey wrote:
> > https://codereview.chromium.org/377213002/diff/1/src/api.cc
> > File src/api.cc (right):
> > 
> > https://codereview.chromium.org/377213002/diff/1/src/api.cc#newcode1249
> > src/api.cc:1249: EscapableHandleScope
> > scope(reinterpret_cast<Isolate*>(isolate));
> > On 2014/07/09 11:41:50, Yang wrote:
> > > Not sure whether we really need the handle scope to get rid of just one
> extra
> > > handle.
> > 
> > Removed.
> 
> ping Sven.

In general we should refrain from silently injecting Handles into the caller's
HandleScope, so the general rule of thumb is to use a (Escapable)HandleScope in
implementation of API functions. I'm not sure if we do it consistently, though,
but we really should, otherwise things get interesting when you use API entries
e.g. in a loop etc.

So the 1st patch set was actually nicer IMHO.

[Yang, 2014-07-10 08:11:07]

On 2014/07/10 07:53:53, Sven Panne wrote:
> On 2014/07/10 07:01:55, Yang wrote:
> > On 2014/07/09 11:46:24, aandrey wrote:
> > > https://codereview.chromium.org/377213002/diff/1/src/api.cc
> > > File src/api.cc (right):
> > > 
> > > https://codereview.chromium.org/377213002/diff/1/src/api.cc#newcode1249
> > > src/api.cc:1249: EscapableHandleScope
> > > scope(reinterpret_cast<Isolate*>(isolate));
> > > On 2014/07/09 11:41:50, Yang wrote:
> > > > Not sure whether we really need the handle scope to get rid of just one
> > extra
> > > > handle.
> > > 
> > > Removed.
> > 
> > ping Sven.
> 
> In general we should refrain from silently injecting Handles into the caller's
> HandleScope, so the general rule of thumb is to use a (Escapable)HandleScope
in
> implementation of API functions. I'm not sure if we do it consistently,
though,
> but we really should, otherwise things get interesting when you use API
entries
> e.g. in a loop etc.
> 
> So the 1st patch set was actually nicer IMHO.

I see. My bad then.

[aandrey, 2014-07-10 08:18:01]

Back to previous patch set

[Yang, 2014-07-10 09:12:42]

On 2014/07/10 08:18:01, aandrey wrote:
> Back to previous patch set

lgtm.

[aandrey, 2014-07-11 09:40:01]

Turns out that we don't need this API. So, I'll leave it up to you whether
commit this or not.

[Sven Panne, 2014-07-15 08:18:36]

On 2014/07/11 09:40:01, aandrey wrote:
> Turns out that we don't need this API. So, I'll leave it up to you whether
> commit this or not.

If it's not used, it will bit-rot, anyway. :-) Therefore, I'm simply closing
this issue, we can easily revive it if it turns out to be needed in the future.