[ignoring everything else in this thread]
Hi,
I have some early prototype work in my branch devs/jpeg/efl_invalidate to
experiment with efl_invalidate.
I am not sure how to exploit it, or if this idea is right, so it's on hold
for now.
If you're interested, have a look, and let us know what your
On Thu, 11 Jan 2018 18:25:37 -0200 Gustavo Sverzut Barbieri
said:
> On Thu, Jan 11, 2018 at 5:54 AM, Carsten Haitzler
> wrote:
> > On Wed, 10 Jan 2018 16:52:26 -0200 Gustavo Sverzut Barbieri
> ...
> >> however, in a more generic OOP system this makes things unusable, as
> >> we're discussing in
On Thu, Jan 11, 2018 at 5:54 AM, Carsten Haitzler wrote:
> On Wed, 10 Jan 2018 16:52:26 -0200 Gustavo Sverzut Barbieri
...
>> however, in a more generic OOP system this makes things unusable, as
>> we're discussing in this thread.
>>
>> parents: wisely we're advertising almost all objects should h
On Thu, Jan 11, 2018 at 6:00 PM, Gustavo Sverzut Barbieri
wrote:
> On Thu, Jan 11, 2018 at 5:56 AM, Jean-Philippe André
> wrote:
> ...
[snip]
>>> WRONG/BUG usage:
>>> o = efl_add(cls, parent, ...); // refcnt = 1, the PARENT's reference
>>> efl_unref(o); // refcnt = 0, but parent held t
On Thu, Jan 11, 2018 at 5:56 AM, Jean-Philippe André wrote:
...
>> if we wish to do cascade deletion, which may be very helpful (delete a
>> loop, get rid of all users... like done for evas + objects), then we
>> can dissociate terminate/invalidate from reference, but the last
>> reference would i
On Thu, 11 Jan 2018 11:16:02 +0900 Jean-Philippe André said:
> Hi
>
> On Wed, Jan 10, 2018 at 11:39 PM, Carsten Haitzler
> wrote:
>
> > On Wed, 10 Jan 2018 16:31:33 +0900 Jean-Philippe André
> > said:
> >
> > > Hi,
> > >
> > > I created a new event "destruct" in Efl.Object.
> > > It's trigger
On Wed, 10 Jan 2018 16:52:26 -0200 Gustavo Sverzut Barbieri
said:
> hi all,
>
> jpeg, i think that this "destruct" event should have a counterpart
> method, like in GObject they have dispose + finalize, we could have
> something like that to allow two clearly distinct phases:
>- one to relea
On Thu, Jan 11, 2018 at 3:52 AM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:
> hi all,
>
> jpeg, i think that this "destruct" event should have a counterpart
> method, like in GObject they have dispose + finalize, we could have
> something like that to allow two clearly distinct phases:
Hi Gustavo,
Just replying to the first comment in this mail.
On Thu, Jan 11, 2018 at 3:52 AM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:
> hi all,
>
> jpeg, i think that this "destruct" event should have a counterpart
> method, like in GObject they have dispose + finalize, we could ha
Hi
On Wed, Jan 10, 2018 at 11:39 PM, Carsten Haitzler
wrote:
> On Wed, 10 Jan 2018 16:31:33 +0900 Jean-Philippe André
> said:
>
> > Hi,
> >
> > I created a new event "destruct" in Efl.Object.
> > It's triggered just before removing the callbacks, in the base class
> > destructor, as it's both e
hi all,
jpeg, i think that this "destruct" event should have a counterpart
method, like in GObject they have dispose + finalize, we could have
something like that to allow two clearly distinct phases:
- one to release references to others (our invalidate/terminate),
announces that everyone keep
On Wed, 10 Jan 2018 16:31:33 +0900 Jean-Philippe André said:
> Hi,
>
> I created a new event "destruct" in Efl.Object.
> It's triggered just before removing the callbacks, in the base class
> destructor, as it's both easier and safer this way. I guess this can be
> used in bindings too.
shouldn
Hi,
I created a new event "destruct" in Efl.Object.
It's triggered just before removing the callbacks, in the base class
destructor, as it's both easier and safer this way. I guess this can be
used in bindings too.
As for the rest, I need to think about it more.
Best regards,
On Wed, Jan 10, 2
On Tue, 9 Jan 2018 21:03:53 +0900 Jean-Philippe André said:
> On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler
> wrote:
>
> > On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André
> > said:
> >
> > > Hi,
> > >
> > >
> > > Some of the argumentation here seems to lack a bit of a scientific
> > >
On Tue, Jan 9, 2018 at 3:17 PM, Carsten Haitzler
wrote:
> On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André
> said:
>
> > Hi,
> >
> >
> > Some of the argumentation here seems to lack a bit of a scientific
> > approach...
> > So, I looked for all occurrences of efl_add() (see PS for methodolo
On Mon, 8 Jan 2018 18:15:13 +0900 Jean-Philippe André said:
> Hi,
>
>
> Some of the argumentation here seems to lack a bit of a scientific
> approach...
> So, I looked for all occurrences of efl_add() (see PS for methodology).
>
> In all of EFL, without specific filters:
>
> Overall: 244 uniq
On Tue, Jan 9, 2018 at 7:30 AM, Cedric Bail wrote:
> > Original Message
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 8, 2018 1:15 AM
> > UTC Time: January 8, 2018 9:15 AM
> > From: j...@videolan.org
> &
> Original Message
> Subject: Re: [E-devel] efl_add causing confusion
> Local Time: January 8, 2018 1:15 AM
> UTC Time: January 8, 2018 9:15 AM
> From: j...@videolan.org
> To: Enlightenment developer list
> - Those numbers differ from the values giv
Hi,
Some of the argumentation here seems to lack a bit of a scientific
approach...
So, I looked for all occurrences of efl_add() (see PS for methodology).
In all of EFL, without specific filters:
Overall: 244 unique classes / 1572 occurrences
No parent: 119 unique classes / 472 occurrences
48%
On Thu, 04 Jan 2018 17:18:35 + Andrew Williams said:
> Hi,
>
> I don't think I can do this any longer. Any comment I make about usability
> is met with
>
> "it's easy to understand if you know the internal state/functioning of the
> object".
believe what you want... i described it in a sin
> Original Message
> Subject: Re: [E-devel] efl_add causing confusion
> Local Time: January 4, 2018 10:21 AM
> UTC Time: January 4, 2018 6:21 PM
> From: barbi...@gmail.com
> To: Enlightenment developer list
>
> On Thu, Jan 4, 2018 at 3:12 PM, Andrew Willi
On Thu, Jan 4, 2018 at 3:12 PM, Andrew Williams wrote:
> Hi,
>
> I would avoid the name efl_release if it is not to do with object lifecycle
> as that is the word ObjectiveC uses in their retain/release pair for memory
> management.
+1 I also find "release" to be something related to object lifec
Hi,
I don't think I can do this any longer. Any comment I make about usability
is met with
"it's easy to understand if you know the internal state/functioning of the
object".
My premise is still
"with efl_add sometimes returning ownership and other times not this is
confusing for the developer"
:
> > Original Message
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 3, 2018 1:43 AM
> > UTC Time: January 3, 2018 9:43 AM
> > From: a...@andywilliams.me
> > To: Enlightenment developer list <
> enlightenment-deve
On Wed, 03 Jan 2018 00:41:30 -0500 Cedric Bail said:
> > The whole efl_del argument just exist because it is kinda poorly
> > named. IMO, del means: get this object to an "empty" state.
> > Just like close to files and hide and unparent to UI objects. efl_del
> > should not steal references under
On Wed, 03 Jan 2018 09:43:16 + Andrew Williams said:
> Hi Cedric,
>
> I think I agree, if we can tidy the definitions then everything should get
> clearer.
>
> efl_add_ref being needed for bindings implies that our definition of
> efl_add was not clean enough in the first place.
we were ve
On Wed, 03 Jan 2018 19:03:39 -0500 Cedric Bail said:
> > Original Message
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 3, 2018 1:43 AM
> > UTC Time: January 3, 2018 9:43 AM
> > From: a...@andywilliams.me
> &
On Wed, 03 Jan 2018 09:36:34 + Andrew Williams said:
> Wow, I guess I walked into that with my "... whatever ..." so let's go 1
> step simpler still:
>
> void some_api(Eo *parent) {
>Eo *var = efl_add(SOME_CLASS, parent);
>
>printf("I got an Eo %p, %s\n", var, efl_name_get(var));
>
> Original Message
> Subject: Re: [E-devel] efl_add causing confusion
> Local Time: January 3, 2018 1:43 AM
> UTC Time: January 3, 2018 9:43 AM
> From: a...@andywilliams.me
> To: Enlightenment developer list
>
> Hi Cedric,
>
> I think I agree, if we
Hi Cedric,
I think I agree, if we can tidy the definitions then everything should get
clearer.
efl_add_ref being needed for bindings implies that our definition of
efl_add was not clean enough in the first place.
If efl_del is "hide and unparent" then maybe what we really need is
efl_gfx_hide and
Wow, I guess I walked into that with my "... whatever ..." so let's go 1
step simpler still:
void some_api(Eo *parent) {
Eo *var = efl_add(SOME_CLASS, parent);
printf("I got an Eo %p, %s\n", var, efl_name_get(var));
// TODO figure whether or not I should release var
efl_unref(var); /
> The whole efl_del argument just exist because it is kinda poorly
> named. IMO, del means: get this object to an "empty" state.
> Just like close to files and hide and unparent to UI objects. efl_del
> should not steal references under people who owns it, the object
> would get deleted at a later
On Tue, 02 Jan 2018 19:19:37 + Andrew Williams said:
> Hi,
>
> I am obviously struggling to explain this with words, so will try with code.
> Take the following code fragment:
>
> void some_api(Eo *parent) {
>Eo *var = efl_add(SOME_CLASS, parent);
>
>... do some stuff with var (pos
Hi,
I am obviously struggling to explain this with words, so will try with code.
Take the following code fragment:
void some_api(Eo *parent) {
Eo *var = efl_add(SOME_CLASS, parent);
... do some stuff with var (possible, acknowledged, race condition) ...
// TODO figure whether or not I
On Tue, 26 Dec 2017 17:46:50 -0200 Felipe Magno de Almeida
said:
> JP, Cedric, me and TAsn have been having this argument for a while.
>
> IMO, the whole problem is that we're thinking of ownership in terms
> of parentship, which is wrong with reference counting. Ownership
> is shared between al
On Tue, 26 Dec 2017 12:19:30 + Andrew Williams said:
> Hi,
>
> With the proposal of efl_add and efl_add_child we remove the need for
> efl_add_ref* as the result of the former becomes consistent in its return
> of owned or not owned references.
no. it's needed for bindings (c++, js, lua etc
JP, Cedric, me and TAsn have been having this argument for a while.
IMO, the whole problem is that we're thinking of ownership in terms
of parentship, which is wrong with reference counting. Ownership
is shared between all reference owners and that's it. That's also
the only sane way for bindings
In the books I have read they consider null being a special case of
behaviour within a method just as confusing as passing a bool like in your
illustration.
Andy
On Tue, 26 Dec 2017 at 12:19, Andrew Williams wrote:
> Hi,
>
> With the proposal of efl_add and efl_add_child we remove the need for
Hi,
With the proposal of efl_add and efl_add_child we remove the need for
efl_add_ref* as the result of the former becomes consistent in its return
of owned or not owned references.
Hopefully Cedric can confirm this as I don’t know the spec.
Right now we have a second one because the first is not
On Sun, 24 Dec 2017 09:23:16 + Andrew Williams said:
> Hi,
>
> Yes invalid access is easier to debug than a memory lean, in general.
> In this situation we are talking about the possible consistent memory leaks
> vs the occasional (race condition) undefined access. The latter is not
> easier
On Sun, 24 Dec 2017 09:16:08 + Andrew Williams said:
> Are you trolling me now?
no. you said its inconsistent. it's consistent. it has a simple rule.
http://www.dictionary.com/browse/consistent
it consistently adheres to the same principles. i described them.
> A method that does two diff
On Sun, 24 Dec 2017 09:20:33 + Andrew Williams said:
> The proposal has 0 occurrences of “NULL”.
it has api examples with parent provided on creation. obviously some objects
will not provide a parent (e.g. a toplevel of a tree that has no parents).
> Andy
>
> On Sun, 24 Dec 2017 at 03:33,
Hi,
Yes invalid access is easier to debug than a memory lean, in general.
In this situation we are talking about the possible consistent memory leaks
vs the occasional (race condition) undefined access. The latter is not
easier to debug.
And if we did find the line at error it would look (using t
The proposal has 0 occurrences of “NULL”.
Andy
On Sun, 24 Dec 2017 at 03:33, Carsten Haitzler wrote:
> On Sat, 23 Dec 2017 11:26:42 + Andrew Williams
> said:
>
> > Hi,
> >
> > Thanks for posting that poll. Very useful.
> > If I may I wish to contradict your assertion that this has all been
Are you trolling me now?
A method that does two different things depending on some magic value /
null flag is a code smell (see Clean Coders if this is not familiar).
Consider this method:
ptr get_mem(string poolname, long bytes) {
If (poolname == NULL)
return malloc(bytes); // MUST be freed
else
On Sat, 23 Dec 2017 11:30:58 + Andrew Williams said:
> Hi,
>
> As this thread seems to be descending into word games and (insert
> appropriate word) contests I will reiterate my concern:
>
> efl_add is inconsistent and that should be addressed.
do it's not. i explained already that it is n
On Sat, 23 Dec 2017 11:26:42 + Andrew Williams said:
> Hi,
>
> Thanks for posting that poll. Very useful.
> If I may I wish to contradict your assertion that this has all been
> discussed before - the poll had *0* consideration for what if parent is
> NULL.
i don't see why it needed to. NUL
On Sat, 23 Dec 2017 11:19:59 + Andrew Williams said:
> As framework developers we should be doing everything in our power to avoid
> undefined behaviour. I’ll take accidents memory leaks any day - there are a
> plethora of tools to solve that but it’s far harder to debug the “app not
> workin
Hi,
As this thread seems to be descending into word games and (insert
appropriate word) contests I will reiterate my concern:
efl_add is inconsistent and that should be addressed.
I hope that is clear enough
Andy
On Thu, 21 Dec 2017 at 13:15, Andrew Williams wrote:
> Hi,
>
> This is now well
Hi,
Thanks for posting that poll. Very useful.
If I may I wish to contradict your assertion that this has all been
discussed before - the poll had *0* consideration for what if parent is
NULL.
If you re-read the accepted proposal you will see that is not the current
behaviour at all. There is a (r
As framework developers we should be doing everything in our power to avoid
undefined behaviour. I’ll take accidents memory leaks any day - there are a
plethora of tools to solve that but it’s far harder to debug the “app not
working correctly sometimes on my system” bug reports.
Andy
On Sat, 23
On Fri, 22 Dec 2017 11:44:32 + Andrew Williams said:
> Hi,
>
> I think your summary about the Gtk is not what you think - read the docs
> further
> https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-new and
> you see that actually the trivial example leaks the reference - just
On Fri, 22 Dec 2017 11:53:32 + Andrew Williams said:
> We do have a showstopper design bug.
see my previous mail. https://phab.enlightenment.org/V7 to be explicit.
discussed. voted on. known compromise. lots of code built on top of that design
decision. not a showstopper by any stretch. it's
On Fri, 22 Dec 2017 11:19:40 -0500 Cedric Bail said:
> > Original Message
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: December 21, 2017 7:18 PM
> > UTC Time: December 22, 2017 3:18 AM
> > From: ras...@rasterman.com
> &
> Original Message
> Subject: Re: [E-devel] efl_add causing confusion
> Local Time: December 21, 2017 7:18 PM
> UTC Time: December 22, 2017 3:18 AM
> From: ras...@rasterman.com
> To: Enlightenment developer list
> Cedric Bail
>> you have an object
We do have a showstopper design bug.
We are managing to work with it because we know how it works internally.
The API must be straight forward and provide consistent, robust options.
Any new user would be asking of efl_add:
*) Do I need to unref the result when I am done?
*) How long is my returne
Hi,
I think your summary about the Gtk is not what you think - read the docs
further
https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-new and
you see that actually the trivial example leaks the reference - just like
an efl_add_ref with no unref or del later.
They are *not* returni
n Fri, 22 Dec 2017 at 03:26 Carsten Haitzler wrote:
>
> > On Thu, 21 Dec 2017 13:29:05 -0500 Cedric Bail said:
> >
> > > Hi,
> > >
> > > > Original Message
> > > > Subject: Re: [E-devel] efl_add causing confusion
> > >
On Fri, 22 Dec 2017 10:10:48 + Andrew Williams said:
> On Fri, 22 Dec 2017 at 09:59 Carsten Haitzler wrote:
>
> > On Fri, 22 Dec 2017 09:43:20 + Andrew Williams
> > said:
> >
> > > Hi,
> > >
> > > I think that maybe I could have explained this a little better, let me
> > step
> > > bac
On Fri, 22 Dec 2017 at 09:59 Carsten Haitzler wrote:
> On Fri, 22 Dec 2017 09:43:20 + Andrew Williams
> said:
>
> > Hi,
> >
> > I think that maybe I could have explained this a little better, let me
> step
> > back from the implementation details for a minute.
> >
> > As a user of this API a
On Fri, 22 Dec 2017 09:43:20 + Andrew Williams said:
> Hi,
>
> I think that maybe I could have explained this a little better, let me step
> back from the implementation details for a minute.
>
> As a user of this API all I want to know is do I have to unref a reference
> that I have been h
gt; > ---- Original Message
> > > Subject: Re: [E-devel] efl_add causing confusion
> > > Local Time: December 21, 2017 9:02 AM
> > > UTC Time: December 21, 2017 5:02 PM
> > > From: a...@andywilliams.me
> > > To: Enlightenment develo
Hi,
I think that maybe I could have explained this a little better, let me step
back from the implementation details for a minute.
As a user of this API all I want to know is do I have to unref a reference
that I have been handed. From this point of view we should be consistent.
My proposal was (
On Thu, 21 Dec 2017 13:29:05 -0500 Cedric Bail said:
> Hi,
>
> > Original Message
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: December 21, 2017 9:02 AM
> > UTC Time: December 21, 2017 5:02 PM
> > From: a...@a
On Thu, 21 Dec 2017 13:15:26 + Andrew Williams said:
> Hi,
>
> This is now well documented (
> https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
> more I use efl_add the more I feel it is confusing especially to new
> developers.
>
> In the current model (if I unders
Hi,
> Original Message
> Subject: Re: [E-devel] efl_add causing confusion
> Local Time: December 21, 2017 9:02 AM
> UTC Time: December 21, 2017 5:02 PM
> From: a...@andywilliams.me
> To: Enlightenment developer list
>
> P.S. if the loss of temporary han
P.S. if the loss of temporary handles with efl_add is not met with
efl_added it would be possible to add a new macro along the lines of:
efl_add_scope(klass, parent) { ... statements ... } whereby the scope of
the variable is valid only within that block.
On Thu, 21 Dec 2017 at 13:15 Andrew Willi
Hi,
This is now well documented (
https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
more I use efl_add the more I feel it is confusing especially to new
developers.
In the current model (if I understand it correctly)
1) child = efl_add(klass, parent) means the child must N
68 matches
Mail list logo
