Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Binding subcomp to child/ren

Aperta
  • Qualcosa non va?
#71 8 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
java
Ambito
compilers

Direzione di ricerca

Inizia dalla documentazione collegata di example1 e dalla discussione nell’issue 2 di org.lemsml.model, quindi esamina i punti di ingresso del parser o dell’interprete che gestiscono gli elementi XML Component e Child. L’issue richiede una regola definita e coerente per il binding dei figli prima che l’implementazione possa essere considerata completata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

According to the docs, the shorthand notation for defining components consists in using ComponentType as the xml-element name instead of <Component type=...>:

[...] Once the units are available it is possible to define a component. There are two equivalent ways of doing this: either by using the Component element and setting its type, or by using the type as a new XML element [...]

In the same example, though, we find

<HHGate id="n" power="4">          
   <Forward type="HHExpLinearRate" rate="0.1per_ms" midpoint="-55mV" scale="10mV" />          
   <Reverse type="HHExpRate" rate="0.125per_ms" midpoint="-65mV" scale="-80mV" />      
</HHGate>

Where <Forward> and <Reverse> are not Component Types (they even have a type attribute), but the name attribute of a Child definition in the ComponentType:

<ComponentType name="HHGate">      
   <Parameter name="power" dimension="none" />       
   <Child name="Forward" type="HHRate" />      
   <Child name="Reverse" type="HHRate" />

In this case, <HHGate> would have two <Child> of type HHRate, and the element name is being used to determine which is which.

One can always argue that <X name="aX"> is nicer to type than <Component type="X" name="aX">, but being able to bend the rules again and use <aX> (if and only if it is a <Child>) seems abusive to me. Consistence is not only good for us writing parsers/interpreters -- which will have a lot of ad-hoc checks to cope with those special cases -- but for users as well, as changing notation in "magic" places tends to be confusing and frustrating.

Keeping the discussion here in mind, I suggest (@robertcannon) to stick to the <X name="aX"> notation (even though I'd like to be radical on the consistency side and abolish the shorthand notation altogether...).

@pgleeson will probably say we have to live with it since it is used all around NeuroML2 - but actually, this seems to be the case (multiple <Child> with the same type) only for Gate opening / closing rates.

Lingua principale
Java
Stelle
13
Fork
11
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LEMS/jLEMS

Tutte le issue di LEMS/jLEMS

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.