Morpho-lang / Morpho-lang/morpho-optimize4

Clarify `optimize4` method names: switch from `lowercase()` to `camelCase()`

Open
#3 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Summary

optimize4 appears to introduce camelCase energy/constraint methods such as opt.addEnergy() and opt.addConstraint(), while the older optimize API uses lowercase methods like opt.addenergy() and opt.addconstraint().

Currently, both naming styles appear to work when importing optimize4, because both method variants are present. It would be helpful to clarify whether the lowercase methods are intentionally supported for backward compatibility, or whether users should migrate to the camelCase API.

Example

Using the older optimize style:

var opt = OptimizationProblem()
opt.addenergy(energy)

Using the new optimize4 style:

var opt = OptimizationProblem()
opt.addEnergy(energy)

Both currently seem to work. For example:

print opt.respondsto()

returns:

[
  addenergy,
  addconstraint,
  updateList,
  invoke,
  prnt,
  clss,
  has,
  setindex,
  clone,
  index,
  count,
  addLocalConstraint,
  addlocalconstraint,
  update,
  linearization,
  serialize,
  respondsto,
  init,
  superclass,
  enumerate,
  addEnergy,
  addConstraint
]

Is this intentional for backward compatibility? If so, should the docs mention that both are supported, and indicate which style is preferred going forward?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by checking how optimize4 exposes addenergy(), addconstraint(), addEnergy(), and addConstraint(), using the reported respondsto() output as the initial reference. Compare this with the older optimize API behavior. Done means the project clearly states whether the lowercase aliases are intentional, which spelling is preferred, and whether compatibility should be documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.