Sujet : Re: REPL in Lisp
De : no_email (at) *nospam* invalid.invalid (Antonio Marques)
Groupes : sci.lang comp.lang.lisp comp.lang.schemeSuivi-à : comp.lang.lispDate : 13. Jul 2024, 00:46:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v6sbof$37ogs$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : NewsTap/5.5 (iPhone/iPod Touch)
Julieta Shem <
jshem@yaxenu.org> wrote:
Follow-up to comp.lang.lisp. Even though it doesn't even belong to
comp.lang.lisp, let's at least free other groups from this topic. Or
provide me with better judgement.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 11 Jul 2024 12:57:12 -0000 (UTC), Antonio Marques wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
the acronym (?) REPL must be new in Lisp (and Scheme)
i'm sure i never saw it (used or mentioned) 25 years ago.
There are many new terms coined for old concepts. Like “capture” for
“lexical binding”, or “dependency injection” for “callback”.
I can more or less see how callbacks can be used as a kind of dependency
injection, but those are separate concepts.
“Dependency injection” is just packaging up a bunch of callbacks as
methods in a class.
Why would you say ``packaging up''? Can we look at Wikipedia? (I'd
appreciate a good reference. I don't know exactly where to look.)
--8<-------------------------------------------------------->8---
[...] dependency injection is a programming technique in which an
object or function receives other objects or functions that it
requires, as opposed to creating them internally. Dependency injection
aims to separate the concerns of constructing objects and using them,
leading to loosely coupled programs.[1][2][3] The pattern ensures that
an object or function that wants to use a given service should not
have to know how to construct those services. Instead, the receiving
'client' (object or function) is provided with its dependencies by
external code (an 'injector'), which it is not aware of. --Wikipedia
--8<-------------------------------------------------------->8---
So I see why you're saying ``callback'' because the object or function
will call your procedures to get what it needs (instead of creating them
internally). But why would say ``packaging up''?
(You shouldn't be trying to make sense of information provided by someone
who admits to not understanding it.)
(Couldn't I
``inject'' the ``dependencies'' by passing them all as arguments.)
That's one way to do it. In languages that rely on 'objects' it's
fashionable to declare a field for each dependency, with an annotation that
says it's a dependency, and some framework will provide the values at run
time (there will be some framework-specific way to instantiate the
dependencies).
I suppose ``packaging up'' would be appropriate if we pass in to a
procedure an object containing all the callbacks that you say.
Anyway, my interpretation of the Wikipedia article is merely
abstraction. Nothing but abstraction. I don't see why we need to call
it ``injection'' or even ``dependency'', even though the choice of words
isn't absurd.
Again, abstraction is just a requirement. There's few things in software
that don't imply some form of abstraction, so that word doesn't get us very
far.
Dependency injection is all about the injection: someone provides your
dependencies for you, and what concrete implementations of those is
something that can and will vary.
(*) The source
Dependency injection
https://en.wikipedia.org/wiki/Dependency_injection