cedet-eieio Mailing List for CEDET

I found my mistake. As a new elisp programmer I still get confused with
quotation...

Best,

Sylvain.


Sylvain Salvati writes:

> Dear list,
>
> I ma trying to use eieio to write code in elisp. But I am stuck with a
> problem related to polymorphism. Here is a simple example showing my
> problem
>
> (defclass a()
>   ((a :initarg :a
>       :initform 0))
>   "class a")
>
> (defclass b()
>   ((b :initarg :b
>       :initform 0))
>   "class b")
>
> (defmethod nb ((xa a))
>   (oref xa :a))
>
> (defmethod nb ((xb b))
>   (oref xb :b))
>
> (setq xa (a))
>
> (setq xb (b))
>
> (nb xa) ;;yields 0 as expected
>
> (nb xb) ;;also yields 0
>
> (mapcar 'nb '(xa xb)) ;; yields cl-no-applicable-method (nb xa)
>
> I create two classes a and b and they both have a method nb. When I have
> a list made of objects that can be either a's or b's I would expect to
> be able to map the method nb on the list, but this fails. Is there a
> workaround this problem.
>
> Thanks,
>
> Sylvain.

Dear list,

I ma trying to use eieio to write code in elisp. But I am stuck with a
problem related to polymorphism. Here is a simple example showing my
problem

(defclass a()
  ((a :initarg :a
      :initform 0))
  "class a")

(defclass b()
  ((b :initarg :b
      :initform 0))
  "class b")

(defmethod nb ((xa a))
  (oref xa :a))

(defmethod nb ((xb b))
  (oref xb :b))

(setq xa (a))

(setq xb (b))

(nb xa) ;;yields 0 as expected

(nb xb) ;;also yields 0

(mapcar 'nb '(xa xb)) ;; yields cl-no-applicable-method (nb xa)

I create two classes a and b and they both have a method nb. When I have
a list made of objects that can be either a's or b's I would expect to
be able to map the method nb on the list, but this fails. Is there a
workaround this problem.

Thanks,

Sylvain.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 29.11.2014 o 14:16, Eric Ludlam pisze:
> On 11/29/2014 05:26 AM, Przemysław Wojnowski wrote:
[...]

>> 3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)? EIEIO is on 
>> language level and Speedbar on GUI level, so both are in completely 
>> different worlds - it's like having dependency from JDK to Eclipse. This 
>> dependency makes all programs that use EIEIO (OO system) to depend on 
>> Speedbar, which they may not need. If a class wants to have Speedbar 
>> support then Speedbar should provide helper classes, not EIEIO.
> 
> Are you thinking of a build/load dependency from eieio-opt.el? Everything 
> in eieio-opt is optional.  It is fine to use eieio without it, or 
> eieio-speedbar.
> 
> The two sets of speedbar support are different though.  The stuff in 
> eieio-opt is for displaying all classes current loaded into Emacs.  The 
> eieio-speedbar stuff is for creating your own classes that have a tree 
> hierarchy of their own, and their own mode.   For example, in EDE you can 
> browse all the project trees.
I just meant that OO layer (EIEIO) and visual tool operating on it (Speedbar)
are separate concerns. OO layer, being just above basic language primitives,
provides abstractions for constructing programs in OO way - for example a
tool for graphical browsing/editing structures of programs built using such OO
layer. So, OO layer should has no dependencies (even conceptual) to programs
built on top of it.

Actually, Speedbar already contains couple of modes (plugins?) for other parts
of Emacs (files, buffers, info, etc.), so why sp-eieio.el is not there too?

I'm not a maintainer of EIEIO, but only learning it and just wanted to
understand some of the decisions. If you disagree, just ignore my emails. :-)

Thanks!
Przemyslaw

> 
> That said, if someone wants to pull the speedbar class browser into it's 
> own utility fcn, that would be fine with me.
> 
> Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUej7iAAoJEC3CE3LuBFUoNKEP/jzH1Nd3xh8oVFJrgNkLbbwy
u/pcrUJlugfY5CIb8EZjubMxc/OPjJqywAPL/U89xB6t+8exFPe0pGumcXo3Mh0j
wq/on5Fu/pRTZuMGMjx5K/Y9u/j/kDhsZOgC4//YE6T9gAP9SqYq2EPtra6N3lW9
mRSNZaRAl/o3Nmmt+L64BHMJvJqCSv2I6pMqMH6qT4xouG+ZeBuowqejVR6/V462
6Sxh8o9ERhd+vGdSFCTsgDe2ZICERwPWn5s4LKxHnKKiHmsIwcP43AUpM+ASFjvW
ptVwzCtuP+utJW4iu/zPZ+ZBOwdSULNLnASymr4wuSDLWgHh6MmANovArivo3m5L
L0Q/vSnqrZ0QowWyVMDQfomCYu+oiK8V3z7RjN5z6virv7JSN8j6scRb5d+0p7VV
kD07DbBDN65gL4Ds6Vp21xxFLqoJPCJUPp7DskwM01YI9qDxI6PHkgiuGrMAe0l6
Qkt2q7Mha2HlxTocFxOmiOkIFnu4VSjapf2YeDdfaeuBFf7bE0X/GhqmLqMu3pef
gehnZGkWfXpG8Pj+BFo72mpmyQbT9Zeyz9l5OWD23Fx3L3/7DQJ6cC+kILhuLdy4
pshCbQ7LfVCiJcaeSmsLK8KWtiZUpFHHAdXz0o4ivkr+fq3/5ORiDkNehZ1d4Dxm
mjftvbacebyQIZ1NVZiR
=n4M8
-----END PGP SIGNATURE-----

On 11/29/2014 05:26 AM, Przemysław Wojnowski wrote:
> Hello everybody,
>
> While learning EIEIO I've encountered the following issues:
> 1. 'describe-class' docs says:
> "(describe-class CLASS &optional HEADERFCN)
>
> Describe a CLASS defined by a string or symbol.
> If CLASS is actually an object, then also display current values of that object."
>
> So, the second sentence says that the argument can be an object, and then the
> function will display values of that object, right? But the following gives error:
[...]
> ELISP> (let ((p (point "a point" :x 1 :y 2)))
>           (describe-class p))
> *** Eval error ***  Wrong type argument: symbolp, [object point "a point" 1 2]
>
> Am I missing something?

Hi Przemyslaw

I think this is a bug in the doc.  I suspect the doc was the intent but 
the code changed over time and the doc wasn't updated.  There isn't a 
handy way to display an object other than the data-debug tool which is 
completely separate.  I'll submit a fix to my local copy, though I think 
the maintenance is moving off to Emacs core RSN if not already so I'm 
not sure yet if it will be propagated.

> 2. Why constructor functions have instance name as required parameter?
> According to the info doc it's for debugging purposes:
> "Each instance is given a name, so different instances can be easily
> distinguished when debugging."
> But it's such a rare case and providing a name for every object makes
> constructors just impractical. When someone needs to name things for debugging
> purposes he/she can easily add a slot for such purpose.

Having the name was important to me while I was working on my projects, 
such as eieio, and other parts of CEDET.   I agree is is a bit annoying 
when just assembling a few simple classes for a test or what-not.  I 
would not be opposed to having the string/name be optional in the future.

> 3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)?
> EIEIO is on language level and Speedbar on GUI level, so both are in completely
> different worlds - it's like having dependency from JDK to Eclipse. This
> dependency makes all programs that use EIEIO (OO system) to depend on Speedbar,
> which they may not need.
> If a class wants to have Speedbar support then Speedbar should provide helper
> classes, not EIEIO.

Are you thinking of a build/load dependency from eieio-opt.el? 
Everything in eieio-opt is optional.  It is fine to use eieio without 
it, or eieio-speedbar.

The two sets of speedbar support are different though.  The stuff in 
eieio-opt is for displaying all classes current loaded into Emacs.  The 
eieio-speedbar stuff is for creating your own classes that have a tree 
hierarchy of their own, and their own mode.   For example, in EDE you 
can browse all the project trees.

That said, if someone wants to pull the speedbar class browser into it's 
own utility fcn, that would be fine with me.

Eric

Hello everybody,

While learning EIEIO I've encountered the following issues:
1. 'describe-class' docs says:
"(describe-class CLASS &optional HEADERFCN)

Describe a CLASS defined by a string or symbol.
If CLASS is actually an object, then also display current values of that object."

So, the second sentence says that the argument can be an object, and then the
function will display values of that object, right? But the following gives error:
ELISP> (defclass point ()
         ((x :initarg :x
             :type number)
          (y :initarg :y
             :type number)))
point
ELISP> (let ((p (point "a point" :x 1 :y 2)))
         (describe-class p))
*** Eval error ***  Wrong type argument: symbolp, [object point "a point" 1 2]

Am I missing something?

2. Why constructor functions have instance name as required parameter?
According to the info doc it's for debugging purposes:
"Each instance is given a name, so different instances can be easily
distinguished when debugging."
But it's such a rare case and providing a name for every object makes
constructors just impractical. When someone needs to name things for debugging
purposes he/she can easily add a slot for such purpose.

3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)?
EIEIO is on language level and Speedbar on GUI level, so both are in completely
different worlds - it's like having dependency from JDK to Eclipse. This
dependency makes all programs that use EIEIO (OO system) to depend on Speedbar,
which they may not need.
If a class wants to have Speedbar support then Speedbar should provide helper
classes, not EIEIO.

Hope you don't get it wrong (as an attack), but as constructive critique. After
all, EIEIO is great piece of software.

Cheers,
Przemyslaw

El vie, 24-01-2014 a las 21:00 +0100, David Engster escribió:

> Jorge Araya Navarro writes:
> > I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I
> > try to start Emacs, I run into this error:
> >
> > Debugger entered--Lisp error: (void-function eieio-object-name-string)
> 
> [...]
> 
> > This happens with both bazar snapshot and the latest snapshot 8634 on http://
> > www.randomsample.de/cedet-snapshots/.
> > Maybe this error is happening because eieio-object-name-string is still named
> > object-name-string until Emacs 24.4?
> 
> The CEDET development version also ships with an up-to-date EIEIO, which
> should override the one in Emacs.
> 
> What happens when you do
> 
> emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el
> 
> Does that work?
> 
> -David
> 
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> cedet-eieio mailing list
> ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-eieio


I manage to make it works, now I have no errors!!
My issue was happening because of this line of code on
my .emacs.d/init.el file:

;; programas elisp que no estan en elpa
(let ((default-directory "~/.emacs.d/otros/"))
      (normal-top-level-add-subdirs-to-load-path))

my cedet snapshot was sitting on ~/.emacs.d/otros/, but I don't fully
know the correlation between my lines of elisp and this issue. This
happens because you don't know what are you doing, do not follow my
example and study elisp, kids :)

Thanks for the support!! :)

-- 
Pax et bonum.
Jorge Araya Navarro.
Diseñador publicitario, programador Python/C++ y colaborador en Parabola
GNU/Linux-libre.

El vie, 24-01-2014 a las 21:00 +0100, David Engster escribió:

> Jorge Araya Navarro writes:
> > I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I
> > try to start Emacs, I run into this error:
> >
> > Debugger entered--Lisp error: (void-function eieio-object-name-string)
> 
> [...]
> 
> > This happens with both bazar snapshot and the latest snapshot 8634 on http://
> > www.randomsample.de/cedet-snapshots/.
> > Maybe this error is happening because eieio-object-name-string is still named
> > object-name-string until Emacs 24.4?
> 
> The CEDET development version also ships with an up-to-date EIEIO, which
> should override the one in Emacs.
> 
> What happens when you do
> 
> emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el
> 
> Does that work?
> 
> -David
> 
> 
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> cedet-eieio mailing list
> ced...@li...
> https://lists.sourceforge.net/lists/listinfo/cedet-eieio


Oh my God!, yes that works, this is what I get from the *Message*
buffer:


For information about GNU Emacs and the GNU system, type C-h C-a.
Loading /home/jorge/.emacs.d/otros/cedet/cedet-remove-builtin.el (source)...done
Loading autoloads from CEDET development.
Parsing  *srecode-map-tmp* (LALR)...done


Just for the record, this is what I get if I try to run Emacs as I
always do:


Loading /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el (source)...
Loading /home/jorge/.emacs.d/otros/cedet/cedet-remove-builtin.el (source)...done
Package assoc is obsolete!
For information about GNU Emacs and the GNU system, type C-h C-a.


What should I do now? load "cedet/cedet-remove-builtin.el" before
"cedet/cedet-devel-load.el" (maybe it makes no sense, but I have to try
something, right?)

-- 
Pax et bonum.
Jorge Araya Navarro.
Diseñador publicitario, programador Python/C++ y colaborador en Parabola
GNU/Linux-libre.

Jorge Araya Navarro writes:
> I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I
> try to start Emacs, I run into this error:
>
> Debugger entered--Lisp error: (void-function eieio-object-name-string)

[...]

> This happens with both bazar snapshot and the latest snapshot 8634 on http://
> www.randomsample.de/cedet-snapshots/.
> Maybe this error is happening because eieio-object-name-string is still named
> object-name-string until Emacs 24.4?

The CEDET development version also ships with an up-to-date EIEIO, which
should override the one in Emacs.

What happens when you do

emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el

Does that work?

-David

Hello!

I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but
when I try to start Emacs, I run into this error:


Debugger entered--Lisp error: (void-function eieio-object-name-string)
  eieio-object-name-string([object ede-project-autoload "android" "ANDROID ROOT" ede/android "AndroidManifest.xml" "" unbound nil ede-android-load ede-android-project nil t t])
  ede-add-project-autoload([object ede-project-autoload "android" "ANDROID ROOT" ede/android "AndroidManifest.xml" "" unbound nil ede-android-load ede-android-project nil t t])
  eval-buffer(#<buffer  *load*-529733> nil "/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" nil t)  ; Reading at buffer position 704
  load-with-code-conversion("/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" "/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" nil t)
  load("ede/loaddefs" nil nomessage)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\307\310\311\312#\207" [require cedet eieio eieio-speedbar ede/source ede/base ede/auto load "ede/loaddefs" nil nomessage] 4)
  require(ede)
  (let ((CEDETDIR (file-name-directory (or load-file-name (buffer-file-name))))) (if (boundp (quote cedet-bootstrap-in-progress)) nil (load-file (expand-file-name "cedet-remove-builtin.el" CEDETDIR))) (add-to-list (quote load-path) CEDETDIR) (add-to-list (quote load-path) (expand-file-name "lisp/cedet" CEDETDIR)) (add-to-list (quote load-path) (expand-file-name "lisp/eieio" CEDETDIR)) (add-to-list (quote load-path) (expand-file-name "lisp/speedbar" CEDETDIR)) (require (quote eieio)) (require (quote ede)) (if (boundp (quote cedet-bootstrap-in-progress)) nil (message "Loading autoloads from CEDET development.") (load (expand-file-name "lisp/eieio/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/speedbar/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/ede/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/cogre/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/srecode/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/semantic/loaddefs.el" CEDETDIR) nil t t) (setq Info-directory-list (cons (expand-file-name "doc/info" CEDETDIR) Info-default-directory-list))) (require (quote cedet-compat)))
  eval-buffer(#<buffer  *load*-93862> nil "/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil t)  ; Reading at buffer position 2893
  load-with-code-conversion("/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" "/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil nil)
  load("/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil nil t)
  load-file("~/.emacs.d/otros/cedet/cedet-devel-load.el")
  eval-buffer(#<buffer  *load*> nil "/home/jorge/.emacs.d/init.el" nil t)  ; Reading at buffer position 218
  load-with-code-conversion("/home/jorge/.emacs.d/init.el" "/home/jorge/.emacs.d/init.el" t t)
  load("/home/jorge/.emacs.d/init" t t)
  #[0 "\205\262 [...]  [init-file-user system-type delayed-warnings-list user-init-file inhibit-default-init inhibit-startup-screen ms-dos "~" "/_emacs" windows-nt "/.emacs" directory-files nil "^\\.emacs\\(\\.elc?\\)?$" "~/.emacs" "^_emacs\\(\\.elc?\\)?$" (initialization "`_emacs' init file is deprecated, please use `.emacs'") "~/_emacs" t load expand-file-name "init" file-name-as-directory "/.emacs.d" file-name-extension "elc" file-name-sans-extension ".el" file-exists-p file-newer-than-file-p message "Warning: %s is newer than %s" sit-for 1 "default"] 7 "\n\n(fn)"]()


This happens with both bazar snapshot and the latest snapshot 8634 on
http://www.randomsample.de/cedet-snapshots/.
Maybe this error is happening because eieio-object-name-string is still
named object-name-string until Emacs 24.4? Well, I have no clue, so I
hope for some help here! :)  
-- 
Pax et bonum.
Jorge Araya Navarro.
Diseñador publicitario, programador Python/C++ y colaborador en Parabola
GNU/Linux-libre.

On Fri, 24 May 2013 05:46:40 +0500, Eric M. Ludlam <er...@si...>  
wrote:

> On 05/21/2013 06:30 AM, Sergey wrote:
>> On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam  wrote:
>>
>>> On 04/14/2013 11:41 AM, Sergey Petrov wrote:
>>>> Hello, I receive following warning during any (e.g. from quick start
>>>> section in manual) method evaluation:
>>>> Warning: Unused lexical variable `scoped-class'
>>>> Does eieio works with lexical binding correctly?
>>>
>>> Hi Sergey,
>>>
>>> Sorry for the slow response.
>>>
>>> The scoped-class feature in EIEIO would indeed break lexical binding.
>>> I'm not that familiar with lexical binding, or how to 'fix' EIEIO to
>>> work with it.
>>>
>>> I'm open to suggestions to how to fix it from the list.
>>>
>>> Eric
>>
>>
>> Thank you. I just wanted a peaceful co-existence for my lexical closures
>> with eieio classes and methods in the same .el file.
>> Probably, the following patch will solve this 'problem'.
>>
>> *** eieio.el	2013-05-21 11:20:04.133759895 +0500
>> *** 1235,1241 ****
>
> Hi Sergey,
>
> Based on this line number, I think you have an old version of eieio.  To  
> aid with byte-compilation in Emacs, eieio.el was split into both  
> eieio.el, and eieio-core.el in the CEDET bzr repository.
>
> You will also find in that same fcn I recently updated it to fix the  
> scoped-class problem so it shouldn't have lexical binding issues anymore.
>
> Perhaps you can try out the latest from CEDET/bzr, and it will fix your  
> issue?
>
> Eric


Yes, in bzr version it is ok. Thank you Eric, and sorry for troubling you.

On 05/21/2013 06:30 AM, Sergey wrote:
> On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam  wrote:
>
>> On 04/14/2013 11:41 AM, Sergey Petrov wrote:
>>> Hello, I receive following warning during any (e.g. from quick start
>>> section in manual) method evaluation:
>>> Warning: Unused lexical variable `scoped-class'
>>> Does eieio works with lexical binding correctly?
>>
>> Hi Sergey,
>>
>> Sorry for the slow response.
>>
>> The scoped-class feature in EIEIO would indeed break lexical binding.
>> I'm not that familiar with lexical binding, or how to 'fix' EIEIO to
>> work with it.
>>
>> I'm open to suggestions to how to fix it from the list.
>>
>> Eric
>
>
> Thank you. I just wanted a peaceful co-existence for my lexical closures
> with eieio classes and methods in the same .el file.
> Probably, the following patch will solve this 'problem'.
>
> *** eieio.el	2013-05-21 11:20:04.133759895 +0500
> *** 1235,1241 ****

Hi Sergey,

Based on this line number, I think you have an old version of eieio.  To 
aid with byte-compilation in Emacs, eieio.el was split into both 
eieio.el, and eieio-core.el in the CEDET bzr repository.

You will also find in that same fcn I recently updated it to fix the 
scoped-class problem so it shouldn't have lexical binding issues anymore.

Perhaps you can try out the latest from CEDET/bzr, and it will fix your 
issue?

Eric

On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam  wrote:

> On 04/14/2013 11:41 AM, Sergey Petrov wrote:
>> Hello, I receive following warning during any (e.g. from quick start
>> section in manual) method evaluation:
>> Warning: Unused lexical variable `scoped-class'
>> Does eieio works with lexical binding correctly?
>
> Hi Sergey,
>
> Sorry for the slow response.
>
> The scoped-class feature in EIEIO would indeed break lexical binding.  
> I'm not that familiar with lexical binding, or how to 'fix' EIEIO to  
> work with it.
>
> I'm open to suggestions to how to fix it from the list.
>
> Eric


Thank you. I just wanted a peaceful co-existence for my lexical closures  
with eieio classes and methods in the same .el file.
Probably, the following patch will solve this 'problem'.

*** eieio.el	2013-05-21 11:20:04.133759895 +0500
*** 1235,1241 ****
       ;; is faster to execute this for not byte-compiled.  ie, install  
this,
       ;; then measure calls going through here.  I wonder why.
       (require 'bytecomp)
!   (let ((byte-compile-warnings nil))
         (byte-compile
          `(lambda (&rest local-args)
     	,doc-string
--- 1235,1242 ----
       ;; is faster to execute this for not byte-compiled.  ie, install  
this,
       ;; then measure calls going through here.  I wonder why.
       (require 'bytecomp)
!   (let ((byte-compile-warnings nil)
! 	  (lexical-binding nil))
         (byte-compile
          `(lambda (&rest local-args)
     	,doc-string

On 04/14/2013 11:41 AM, Sergey Petrov wrote:
> Hello, I receive following warning during any (e.g. from quick start
> section in manual) method evaluation:
> Warning: Unused lexical variable `scoped-class'
> Does eieio works with lexical binding correctly?

Hi Sergey,

Sorry for the slow response.

The scoped-class feature in EIEIO would indeed break lexical binding. 
I'm not that familiar with lexical binding, or how to 'fix' EIEIO to 
work with it.

I'm open to suggestions to how to fix it from the list.

Eric

Hello, I receive following warning during any (e.g. from quick start section in manual) method evaluation:

Warning: Unused lexical variable `scoped-class'
Does eieio works with lexical binding correctly?

> Could please eieio-oref/eieio-oset be avoided?  oref/oset are so often
> used that people will start aliasing them anyways.

CLOS seems to live just fine with `slot-value', so why not just use
`cl-slot-value'?
[ BTW, since setf is now part of core Elisp, we don't need oset.  ]

> How about replacing eieio-, the most awkward prefix in existence, with

Actually, I find it easy to type, because of the "ei" repetition and
because the "o" is right next to the "i".


        Stefan

  >> Stefan Monnier <mo...@ir...>
  >> on Thu, 14 Feb 2013 17:16:21 -0500 wrote:

 >>> Actually, there's a misunderstanding here:
 >>> - setf was indeed part of CL, but being a macro it was accepted
 >>> (i.e. you don't need to have it defined at run-time, since it's
 >>> macro-expanded during compilation).
 >>> - setf is part of core Elisp in Emacs-24.3.
 >>> So maybe we don't need oref/oset at all.
 >> Yes, although I like "(oset foo bar 'baz)" much better than the verbose
 >> (setf (cl-slot-value foo 'bar) 'baz)
 >> But I can understand that you want to get rid of it, and package writers
 >> can still define their own macros/accessors.

 > I actually don't particular care if we keep them or not, except that if
 > we keep them, we need to give them a prefix.

Could please eieio-oref/eieio-oset be avoided?  oref/oset are so often
used that people will start aliasing them anyways.

How about replacing eieio-, the most awkward prefix in existence, with
simple "eo-", standing for Emacs Objects? Then eoref/eoset can be used
as (almost) namespace clean alternatives.

    Vitalie

On 02/19/2013 02:49 PM, David Engster wrote:
> Stefan Monnier writes:
>> For the CL package we solved this problem by leaving the "cl.el" package
>> as a "compatibility package" only required by the packages that haven't
>> been updated to use the new names.  CL was so widely used that it will
>> take a *long* time to get rid of all uses of the old names, whereas
>> EIEIO's use is not as pervasive, so we don't necessarily have to do the
>> same for it.
>> This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el"
>> (with clean names, autoloaded from cl-lib) and then make eieio.el
>> into a simple compatibility package full of aliases.
>
> What to do with the other files like eieio-base then? We cannot rename
> it to cl-eieio-base.el because of name clashes, but it also provides
> part of the public, CLOS-like functions.

There is nothing in eieio-base from CLOS.  Those are all just handy 
base-classes / concepts that I used elsewhere in CEDET.

> To summarize the options so far:
>
> 1) Prefix everything with eieio- and be done with it. Create obsolete
>     aliases for the old names and get rid of them "soon" (Emacs
>     25?). Alternatively, create an eieio-compat package with aliases for
>     the old names.
>
> 2) Prefix everything with eieio- and create cl- aliases for the
>     CLOS-like functionality. Those aliases may be defined in
>
>     2a) the eieio* files itself, or
>     2b) in a separate cl-whatever.el file.
>
>     As in 1), define obsolete aliases for the old names or use a compat
>     package.
>
> 3) Rename eieio to cl-eieio with clean names (i.e., eieio- and
>     cl-prefixes), autoloaded from cl-lib, and make eieio.el a simple
>     compatibility package full of aliases.
>
> I'm currently pretty much tied on "2b)+compat package" and 3).

I am fine with most of these ideas, but agree with David that option 3 
is pretty good.

Eric

>> Only if we can hope to get rid of those aliases soon, because we'd
>> rather not have those compatibility aliases use up the namespace even
>> when all the packages in use have been updated to use the "clean" names.
> Well, you've started aliasing `class-name' in your patch, so I thought
> that was the plan.

Either these aliases will stay as they are until they're removed, or we
can move them to a separate package.  I saw no need to make such
a choice at this point.


        Stefan

Stefan Monnier writes:
>> I meant a compat package in CEDET upstream, so that it can run on older
>> Emacsen if we stop shipping our own EIEIO version.  As long as we're
>> obsolete-aliasing the old names, I don't see why we would need a compat
>> package in Emacs?
>
> Only if we can hope to get rid of those aliases soon, because we'd
> rather not have those compatibility aliases use up the namespace even
> when all the packages in use have been updated to use the "clean" names.

Well, you've started aliasing `class-name' in your patch, so I thought
that was the plan.

> For the CL package we solved this problem by leaving the "cl.el" package
> as a "compatibility package" only required by the packages that haven't
> been updated to use the new names.  CL was so widely used that it will
> take a *long* time to get rid of all uses of the old names, whereas
> EIEIO's use is not as pervasive, so we don't necessarily have to do the
> same for it.
> This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el"
> (with clean names, autoloaded from cl-lib) and then make eieio.el
> into a simple compatibility package full of aliases.

What to do with the other files like eieio-base then? We cannot rename
it to cl-eieio-base.el because of name clashes, but it also provides
part of the public, CLOS-like functions.

To summarize the options so far:

1) Prefix everything with eieio- and be done with it. Create obsolete
   aliases for the old names and get rid of them "soon" (Emacs
   25?). Alternatively, create an eieio-compat package with aliases for
   the old names.

2) Prefix everything with eieio- and create cl- aliases for the
   CLOS-like functionality. Those aliases may be defined in

   2a) the eieio* files itself, or
   2b) in a separate cl-whatever.el file.

   As in 1), define obsolete aliases for the old names or use a compat
   package.

3) Rename eieio to cl-eieio with clean names (i.e., eieio- and
   cl-prefixes), autoloaded from cl-lib, and make eieio.el a simple
   compatibility package full of aliases.

I'm currently pretty much tied on "2b)+compat package" and 3).

-David

> I meant a compat package in CEDET upstream, so that it can run on older
> Emacsen if we stop shipping our own EIEIO version.  As long as we're
> obsolete-aliasing the old names, I don't see why we would need a compat
> package in Emacs?

Only if we can hope to get rid of those aliases soon, because we'd
rather not have those compatibility aliases use up the namespace even
when all the packages in use have been updated to use the "clean" names.

For the CL package we solved this problem by leaving the "cl.el" package
as a "compatibility package" only required by the packages that haven't
been updated to use the new names.  CL was so widely used that it will
take a *long* time to get rid of all uses of the old names, whereas
EIEIO's use is not as pervasive, so we don't necessarily have to do the
same for it.
This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el"
(with clean names, autoloaded from cl-lib) and then make eieio.el
into a simple compatibility package full of aliases.


        Stefan

>> eieio's extensive abuse of eval-and-compile is a real pain in the rear!
>> Does the additional patch below make it work for you?
> Yes, it now compiles.

Thanks.  I installed it into Emacs's trunk.


        Stefan

Stefan Monnier writes:
>>> Actually, there's a misunderstanding here:
>>> - setf was indeed part of CL, but being a macro it was accepted
>>> (i.e. you don't need to have it defined at run-time, since it's
>
>>> macro-expanded during compilation).
>>> - setf is part of core Elisp in Emacs-24.3.
>>> So maybe we don't need oref/oset at all.
>> Yes, although I like "(oset foo bar 'baz)" much better than the verbose
>> (setf (cl-slot-value foo 'bar) 'baz)
>> But I can understand that you want to get rid of it, and package writers
>> can still define their own macros/accessors.
>
> I actually don't particular care if we keep them or not, except that if
> we keep them, we need to give them a prefix.

OK. I guess we'd have to use eieio-oref/oset then, since those functions
are not from CLOS (given that 'cl' means that thing I thought it means,
but I might just be confused :) ).

>> Our problem on the CEDET side is that we want to stay compatible with
>> older Emacsen, so we'll need some compat package.
>
> We can either introduce an eieio-compat package full of defaliases, or
> do what we did with cl/cl-lib and turn eieio.el into a deprecated compat
> package (and introduce a new package eieio-lib to replace it).

I meant a compat package in CEDET upstream, so that it can run on older
Emacsen if we stop shipping our own EIEIO version. As long as we're
obsolete-aliasing the old names, I don't see why we would need a compat
package in Emacs?

-David

Stefan Monnier writes:
>>>>>> In toplevel form:
>>>>>> eieio.el:168:1:Error: Symbol's function definition is void:
>>>>>> eieio--class-parent
>
>>>>> Can you (setq byte-compile-error t debug-on-error t) so as to get
>>>>> a backtrace?
>>>> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just
>>>> don't get a backtrace with debug-on-error.
>>> No, I meant byte-compile-debug sorry.
>> Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I
>> gzipped it.
>
> eieio's extensive abuse of eval-and-compile is a real pain in the rear!
> Does the additional patch below make it work for you?

Yes, it now compiles.

-David

>>>>> In toplevel form:
>>>>> eieio.el:168:1:Error: Symbol's function definition is void:
>>>>> eieio--class-parent
>>>> Can you (setq byte-compile-error t debug-on-error t) so as to get
>>>> a backtrace?
>>> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just
>>> don't get a backtrace with debug-on-error.
>> No, I meant byte-compile-debug sorry.
> Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I
> gzipped it.

eieio's extensive abuse of eval-and-compile is a real pain in the rear!
Does the additional patch below make it work for you?


        Stefan


--- lisp/emacs-lisp/eieio.el.orig       2013-02-17 12:06:09.252331190 -0500
+++ lisp/emacs-lisp/eieio.el    2013-02-17 12:06:20.336456193 -0500
@@ -121,10 +121,9 @@
                  (list 'aref x ,index))
               defs)
         (setq index (1+ index))))
-    `(progn
+    `(eval-and-compile
        ,@(nreverse defs)
-       (eval-and-compile
-         (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index)))))
+       (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index))))
 
 (eieio--define-field-accessors class
   (-unused-0 ;;FIXME: not sure, but at least there was no accessor!

Stefan Monnier writes:
>>>> In toplevel form:
>>>> eieio.el:168:1:Error: Symbol's function definition is void:
>>>> eieio--class-parent
>>> Can you (setq byte-compile-error t debug-on-error t) so as to get
>>> a backtrace?
>> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just
>> don't get a backtrace with debug-on-error.
>
> No, I meant byte-compile-debug sorry.

Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I
gzipped it.

-David