Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Binding subcomp to child/ren

Đang mở
#71 8 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
java
Lĩnh vực
compilers

Hướng nghiên cứu

Bắt đầu với tài liệu example1 được liên kết và phần thảo luận trong issue 2 của org.lemsml.model, sau đó kiểm tra các điểm đầu vào của parser hoặc interpreter xử lý các phần tử XML Component và Child. Issue này cần một quy tắc rõ ràng, nhất quán cho việc binding các phần tử con trước khi có thể coi việc triển khai là hoàn tất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
13
Fork
11
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của LEMS/jLEMS

Tất cả issue của LEMS/jLEMS

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.