precedence and combination

Common Lisp CLOS 继承与方法组合
本文深入解析 Common Lisp 的 CLOS (Common Lisp Object System) 中类的继承顺序及方法组合机制,包括标准方法组合、广义函数、特殊方法及方法组合类型等核心概念。

一:precedence list

(defclass e()
  ((ce :initform "ce2" :accessor ce)
   (ef :initform "ef1" :accessor ef)
   (eb :initform "eb1" :accessor eb)))
(defclass f()
  ((cf :initform "cf2" :accessor cf)
   (ef :initform "ef2" :accessor ef)
   (fb :initform "fb1" :accessor fb)))  
(defclass c(e f)
  ((ac :initform "ac2" :accessor ac)
   (ce :initform "ce1" :accessor ce)
   (cf :initform "cf1" :accessor cf)))

(defclass h()
  ((bh :initform "bh2" :accessor bh)
   (hj :initform "hj1" :accessor hj)))
(defclass j()
  ((bj :initform "bj2" :accessor bj)
   (hj :initform "hj2" :accessor hj)))
(defclass b(h j)
  ((ab :initform "ab2" :accessor ab)
   (bh :initform "bh1" :accessor bh)
   (bj :initform "bj1" :accessor bj)
   (fb :initform "fb2" :accessor fb)
   (cf :initform "cf2" :accessor cf)))

(defclass A(c b)
  ((ac :initform "ac1" :accessor ac)
   (ab :initform "ab1" :accessor ab)))
CL-USER> (defparameter *kk* (make-instance 'a))  *KK*
CL-USER> (fb *kk*)                               "fb1"
CL-USER> (eb *kk*)                               "eb1"
CL-USER> (ce *kk*)                               "ce1"
CL-USER> (ef *kk*)                               "ef1"


最后你会发现类之间继承的先后顺序是A->C->E->F->B->H->J->standard object->T跟我们平常说的前序查询类似。

对于类的关系比较复杂的话,你首先得画制class hierarchy,原则就是从类开始,然后向上到达直接父类,并且按照直接继承里面父类的顺序从左向右放置在一行,然后按照这种方式依次查找这些类的直接父类。

下面是子类继承的顺序原则,也就是先后顺序。

The precedence list for a class can be computed by traversing the corresponding

network as follows:

1. Start at the bottom of the network.

2. Walk upward, always taking the leftmost unexplored branch.

3. If you are about to enter a node and you notice another path entering the same node from the right, then instead of entering the node, retrace your steps until you get to a node with an unexplored path leading upward. Go back to step 2.

4. When you get to the node representing t , you're done. The order in which you first entered each node determines its place in the precedence list.

广义函数进行继承时的各种形式:

Here is a method for combine that's specialized on numbers:

(defmethod combine ((x number) (y number))

(+ x y))

Methods can even be specialized on individual objects, as determined by eql:

(defmethod combine ((x (eql 'powder)) (y (eql 'spark)))

'boom)

2standard method combination. 

This is called standard method combination. In standard method combination,

calling a generic function invokes

1. The most specific around-method, if there is one.

2. Otherwise, in order,

(a) All before-methods, from most specific to least specific.

(b) The most specific primary method.

(c) All after-methods, from least specific to most specific

The value returned is the value of the around-method (in case 1) or the value of the most specific primary method (in case 2).

CL-USER> (defclass speaker ()())
CL-USER> (defmethod speak ((s speaker) string)
	  		 (format t "~A" string))

;;;由实参匹配到最符合的
CL-USER> (speak (make-instance 'speaker) "I'm hungry")
I'm hungry
NIL

CL-USER> (defclass intellectual (speaker) ())
CL-USER> (defmethod speak :before ((i intellectual ) string)
	 		  (princ "Perhaps "))
CL-USER> (defmethod speak :after ((i intellectual) string)
			   (princ " in some sense"))

;;;利用上面的原则:首先最相关的before到最不相关,然后是最相关的主函数,最后是最不想关到最相关的after
CL-USER> (speak (make-instance 'intellectual) "I'm hungry")
Perhaps I'm hungry in some sense
NIL
CL-USER> (defmethod speak :before ((s speaker) string)
	   		(princ "I think "))

;;;始终执行一个最相关的主方法
CL-USER> (speak (make-instance 'intellectual) "I'm hungry")
Perhaps I think I'm hungry in some sense
NIL
CL-USER> (defmethod speak ((i intellectual) string)
	  		 (format t ", now"))
CL-USER> (speak (make-instance 'intellectual) "I'm hungry")
Perhaps I think , now in some sense
NIL

;;;对于主方法你可以通过call-next-method来调用,比他自己不想关的方法。
CL-USER> (defmethod speak ((i intellectual) string)
	 		  (format t ", now"))
CL-USER> (defmethod speak ((i intellectual) string)
	  		 (format t ", now")
        	 (call-next-method))
CL-USER> (speak (make-instance 'intellectual) "I'm hungry")
Perhaps I think , nowI'm hungry in some sense
NIL

;;;当遇到around关键字时,你必须有call-next-method才能够继续往下处理
CL-USER> (defclass courtier (speaker) ())
CL-USER> (defmethod speak :around ((c courtier) string)
	 		  (format t "Does the King believe that ~A? " string)
	  		  (if (eql (read) 'yes)
	       		(if (next-method-p) (call-next-method))
	      		(format t "Indeed, it is a preposterous idea.~%" 'bow)))
CL-USER> (speak (make-instance 'courtier) "kings will last")
Does the King believe that kings will last? y
Indeed, it is a preposterous idea.
NIL
CL-USER> (speak (make-instance 'courtier) "the world is round")
Does the King believe that the world is round? n
Indeed, it is a preposterous idea.
NIL
3Method combination

有的时候你会组合所有可以应用的主方法(包括从最匹配到最不匹配)的结果,比方说你想用operator method把所有的结果组合起来,比如你定义了一个price的广义函数现在想用+把所有的可以匹配的方法的结果结合起来,也就是下面的形式,其中args表示的实参,因为你需要根据实参找到precedence list.

我们可以在广义函数里面用关键字:method-combination来指定the type of method combination

CL-USER> (defgeneric price (x)
	  		 (:method-combination +))

现在+就作为了method combination,然后所有的price方法必须把+作为第二个参数

CL-USER> (defclass jacket () ())
CL-USER> (defclass trousers () ())
CL-USER> (defgeneric price (x)
	   		(:method-combination +))
CL-USER> (defclass suit (jacket trousers) ())
CL-USER> (defmethod price + ((jk jacket)) 350)
CL-USER> (defmethod price + ((tr trousers)) 200)
CL-USER> (price (make-instance 'suit))
550

从上面可以发现这些主函数是自动调用的,从最关联到最不关联,不需要再用call-next-method 也千万不要用,否则会报错。当时你仍旧可以用around,像前面一样,必须用call-next-method才能够调用primary method。同时注意:before :after方法不能再用了,详见下面的例子:

CL-USER> (defmethod price :around((st suit))
	   (format t "~s~%"  "around"))
CL-USER> (price (make-instance 'suit))
"around"
NIL
;;;仍旧需要around 调用call-next-method来调用主函数,
CL-USER> (defmethod price :around((st suit))
	   (format t "~s~%"  "around")
	   (call-next-method))
上面只是一个operator +的实现方式,我们还有一些其他的method combine。+  append  and  list  max  min  nconc  or  progn


总结:1:首先定义一些类,用于一些广义函数进行defmethod的时候,进行特化。

            2:定义完defmethod,然后我们根据实参,原则:如果defmethod中的特化符是我们提供的实参的类名或他的一个基类的名字。我们就认为是匹配的。

            3:根据我前面如何得到predecence list的标准进行排序。

            4:从那些applicable method中找到含有:before :after :around关键字的方法。然后根据standard method combine进行处理。 这也给我们一个信息就是所有的函数先看实参匹配,最后才是这些combine。

            5:注意其它method combine的构造方式。

Gerrit Code Review - Searching Changes version v3.3.3 Table of Contents Default Searches Basic Change Search Search Operators Argument Quoting Boolean Operators Negation AND OR Labels Magical Operators Default Searches Most basic searches can be viewed by clicking on a link along the top menu bar. The link will prefill the search box with a common search query, execute it, and present the results. Description Default Query All > Open status:open '(or is:open)' All > Merged status:merged All > Abandoned status:abandoned My > Watched Changes is:watched is:open My > Starred Changes is:starred My > Draft Comments has:draft Open changes in Foo status:open project:Foo Basic Change Search Similar to many popular search engines on the web, just enter some text and let Gerrit figure out the meaning: Description Examples Legacy numerical id 15183 Full or abbreviated Change-Id Ic0ff33 Full or abbreviated commit SHA-1 d81b32ef Email address user@example.com For change searches (i.e. those using a numerical id, Change-Id, or commit SHA1), if the search results in a single change that change will be presented instead of a list. For more predictable results, use explicit search operators as described in the following section. Search Operators Operators act as restrictions on the search. As more operators are added to the same query string, they further restrict the returned results. Search can also be performed by typing only a text with no operator, which will match against a variety of fields. age:'AGE' Amount of time that has expired since the change was last updated with a review comment or new patch set. The age must be specified to include a unit suffix, for example -age:2d: s, sec, second, seconds m, min, minute, minutes h, hr, hour, hours d, day, days w, week, weeks (1 week is treated as 7 days) mon, month, months (1 month is treated as 30 days) y, year, years (1 year is treated as 365 days) age can be used both forward and backward looking: age:2d means 'everything older than 2 days' while -age:2d means 'everything with an age of at most 2 days'. assignee:'USER' Changes assigned to the given user. attention:'USER' Changes whose attention set includes the given user. before:'TIME'/until:'TIME' Changes modified before the given 'TIME', inclusive. Must be in the format 2006-01-02[ 15:04:05[.890][ -0700]]; omitting the time defaults to 00:00:00 and omitting the timezone defaults to UTC. after:'TIME'/since:'TIME' Changes modified after the given 'TIME', inclusive. Must be in the format 2006-01-02[ 15:04:05[.890][ -0700]]; omitting the time defaults to 00:00:00 and omitting the timezone defaults to UTC. change:'ID' Either a legacy numerical 'ID' such as 15183, or a newer style Change-Id that was scraped out of the commit message. conflicts:'ID' Changes that conflict with change 'ID'. Change 'ID' can be specified as a legacy numerical 'ID' such as 15183, or a newer style Change-Id that was scraped out of the commit message. destination:'NAME' Changes which match the current user’s destination named 'NAME'. (see Named Destinations). owner:'USER', o:'USER' Changes originally submitted by 'USER'. The special case of owner:self will find changes owned by the caller. ownerin:'GROUP' Changes originally submitted by a user in 'GROUP'. query:'NAME' Changes which match the current user’s query named 'NAME' (see Named Queries). reviewer:'USER', r:'USER' Changes that have been, or need to be, reviewed by 'USER'. The special case of reviewer:self will find changes where the caller has been added as a reviewer. cc:'USER' Changes that have the given user CC’ed on them. The special case of cc:self will find changes where the caller has been CC’ed. revertof:'ID' Changes that revert the change specified by the numeric 'ID'. submissionid:'ID' Changes that have the specified submission 'ID'. reviewerin:'GROUP' Changes that have been, or need to be, reviewed by a user in 'GROUP'. commit:'SHA1' Changes where 'SHA1' is one of the patch sets of the change. project:'PROJECT', p:'PROJECT' Changes occurring in 'PROJECT'. If 'PROJECT' starts with ^ it matches project names by regular expression. The dk.brics.automaton library is used for evaluation of such patterns. projects:'PREFIX' Changes occurring in projects starting with 'PREFIX'. parentproject:'PROJECT' Changes occurring in 'PROJECT' or in one of the child projects of 'PROJECT'. repository:'REPOSITORY', repo:'REPOSITORY' Changes occurring in 'REPOSITORY'. If 'REPOSITORY' starts with ^ it matches repository names by regular expression. The dk.brics.automaton library is used for evaluation of such patterns. repositories:'PREFIX', repos:'PREFIX' Changes occurring in repositories starting with 'PREFIX'. parentrepository:'REPOSITORY', parentrepo:'REPOSITORY' Changes occurring in 'REPOSITORY' or in one of the child repositories of 'REPOSITORY'. branch:'BRANCH' Changes for 'BRANCH'. The branch name is either the short name shown in the web interface or the full name of the destination branch with the traditional 'refs/heads/' prefix. If 'BRANCH' starts with ^ it matches branch names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns. intopic:'TOPIC' Changes whose designated topic contains 'TOPIC', using a full-text search. If 'TOPIC' starts with ^ it matches topic names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns. topic:'TOPIC' Changes whose designated topic matches 'TOPIC' exactly. This is often combined with 'branch:' and 'project:' operators to select all related changes in a series. hashtag:'HASHTAG' Changes whose hashtag matches 'HASHTAG'. The match is case-insensitive. cherrypickof:'CHANGE[,PATCHSET]' Changes which were created using the 'cherry-pick' functionality and whose source change number matches 'CHANGE' and source patchset number matches 'PATCHSET'. Note that 'PATCHSET' is optional. For example, a cherrypickof:12345 matches all changes which were cherry-picked from change 12345 and cherrypickof:12345,2 matches all changes which were cherry-picked from the 2nd patchset of change 12345. ref:'REF' Changes where the destination branch is exactly the given 'REF' name. Since 'REF' is absolute from the top of the repository it must start with 'refs/'. If 'REF' starts with ^ it matches reference names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns. tr:'ID', bug:'ID' Search for changes whose commit message contains 'ID' and matches one or more of the trackingid sections in the server’s configuration file. This is typically used to search for changes that fix a bug or defect by the issue tracking system’s issue identifier. label:'VALUE' Matches changes where the approval score 'VALUE' has been set during a review. See labels below for more detail on the format of the argument. message:'MESSAGE' Changes that match 'MESSAGE' arbitrary string in the commit message body. comment:'TEXT' Changes that match 'TEXT' string in any comment left by a reviewer. path:'PATH' Matches any change touching file at 'PATH'. By default exact path matching is used, but regular expressions can be enabled by starting with ^. For example, to match all XML files use file:^.*\.xml$. The dk.brics.automaton library is used for the evaluation of such patterns. The ^ required at the beginning of the regular expression not only denotes a regular expression, but it also has the usual meaning of anchoring the match to the start of the string. To match all Java files, use file:^.*\.java. The entire regular expression pattern, including the ^ character, should be double quoted when using more complex construction (like ones using a bracket expression). For example, to match all XML files named like 'name1.xml', 'name2.xml', and 'name3.xml' use file:"^name[1-3].xml". Slash ('/') is used path separator. More examples: * -file:^path/. - changes that do not modify files from path/, * file:{^~(path/.)} - changes that modify files not from path/ (but may contain files from path/). file:'NAME', f:'NAME' Matches any change touching a file containing the path component 'NAME'. For example a file:src will match changes that modify files named gerrit-server/src/main/java/Foo.java. Name matching is exact match, file:Foo.java finds any change touching a file named exactly Foo.java and does not match AbstractFoo.java. Regular expression matching can be enabled by starting the string with ^. In this mode file: is an alias of path: (see above). extension:'EXT', ext:'EXT' Matches any change touching a file with extension 'EXT', case-insensitive. The extension is defined as the portion of the filename following the final .. Files with no . in their name have no extension and can be matched by an empty string. onlyextensions:'EXT_LIST', onlyexts:'EXT_LIST' Matches any change touching only files with extensions that are listed in 'EXT_LIST' (comma-separated list). The matching is done case-insensitive. An extension is defined as the portion of the filename following the final .. Files with no . in their name have no extension and can be matched by an empty string. directory:'DIR', dir:'DIR' Matches any change where the current patch set touches a file in the directory 'DIR'. The matching is done case-insensitive. 'DIR' can be a full directory name, a directory prefix or any combination of intermediate directory segments. E.g. a change that touches a file in the directory 'a/b/c' matches for 'a/b/c', 'a', 'a/b', 'b', 'b/c' and 'c'. Slash ('/') is used path separator. Leading and trailing slashes are allowed but are not mandatory. If 'DIR' starts with ^ it matches directories and directory segments by regular expression. The dk.brics.automaton library is used for evaluation of such patterns. footer:'FOOTER' Matches any change that has 'FOOTER' as footer in the commit message of the current patch set. 'FOOTER' can be specified verbatim ('<key>: <value>', must be quoted) or as '<key>=<value>'. The matching is done case-insensitive. star:'LABEL' Matches any change that was starred by the current user with the label 'LABEL'. E.g. if changes that are not interesting are marked with an ignore star, they could be filtered out by '-star:ignore'. 'star:star' is the same as 'has:star' and 'is:starred'. has:draft True if there is a draft comment saved by the current user. has:star Same as 'is:starred' and 'star:star', true if the change has been starred by the current user with the default label. has:stars True if the change has been starred by the current user with any label. has:edit True if the change has inline edit created by the current user. has:unresolved True if the change has unresolved comments. is:assigned True if the change has an assignee. is:starred Same as 'has:star', true if the change has been starred by the current user with the default label. is:unassigned True if the change does not have an assignee. is:watched True if this change matches one of the current user’s watch filters, and thus is likely to notify the user when it updates. is:reviewed True if any user has commented on the change more recently than the last update (comment or patch set) from the change owner. is:owner True on any change where the current user is the change owner. Same as owner:self. is:reviewer True on any change where the current user is a reviewer. Same as reviewer:self. is:cc True on any change where the current user is in CC. Same as cc:self. is:open, is:pending, is:new True if the change is open. is:closed True if the change is either merged or abandoned. is:merged, is:abandoned Same as status:'STATE'. is:submittable True if the change is submittable according to the submit rules for the project, for example if all necessary labels have been voted on. This operator only takes into account one change at a time, not any related changes, and does not guarantee that the submit button will appear for matching changes. To check whether a submit button appears, use the Get Revision Actions API. Equivalent to submittable:ok. is:mergeable True if the change has no merge conflicts and could be merged into its destination branch. Mergeability of abandoned changes is not computed. This operator will not find any abandoned but mergeable changes. This operator only works if Gerrit indexes 'mergeable'. See indexMergeable for details. is:ignored True if the change is ignored. Same as star:ignore. is:private True if the change is private, ie. only visible to owner and its reviewers. is:wip True if the change is Work In Progress. is:merge True if the change is a merge commit. 🔗 status:open, status:pending, status:new True if the change state is 'review in progress'. status:reviewed Same as 'is:reviewed', matches if any user has commented on the change more recently than the last update (comment or patch set) from the change owner. status:closed True if the change is either 'merged' or 'abandoned'. status:merged Change has been merged into the branch. status:abandoned Change has been abandoned. added:'RELATION''LINES', deleted:'RELATION''LINES', delta/size:'RELATION''LINES' True if the number of lines added/deleted/changed satisfies the given relation for the given number of lines. For example, added:>50 will be true for any change which adds at least 50 lines. Valid relations are >=, >, <=, <, or no relation, which will match if the number of lines is exactly equal. commentby:'USER' Changes containing a top-level or inline comment by 'USER'. The special case of commentby:self will find changes where the caller has commented. from:'USER' Changes containing a top-level or inline comment by 'USER', or owned by 'USER'. Equivalent to (owner:USER OR commentby:USER). reviewedby:'USER' Changes where 'USER' has commented on the change more recently than the last update (comment or patch set) from the change owner. author:'AUTHOR' Changes where 'AUTHOR' is the author of the current patch set. 'AUTHOR' may be the author’s exact email address, or part of the name or email address. committer:'COMMITTER' Changes where 'COMMITTER' is the committer of the current patch set. 'COMMITTER' may be the committer’s exact email address, or part of the name or email address. submittable:'SUBMIT_STATUS' Changes having the given submit record status after applying submit rules. Valid statuses are in the status field of SubmitRecord. This operator only applies to the top-level status; individual label statuses can be searched by label. unresolved:'RELATION''NUMBER' True if the number of unresolved comments satisfies the given relation for the given number. For example, unresolved:>0 will be true for any change which has at least one unresolved comment while unresolved:0 will be true for any change which has all comments resolved. Valid relations are >=, >, <=, <, or no relation, which will match if the number of unresolved comments is exactly equal. Argument Quoting Operator values that are not bare words (roughly A-Z, a-z, 0-9, @, hyphen, dot and underscore) must be quoted for the query parser. Quoting is accepted as either double quotes (e.g. message:"the value") or as matched curly braces (e.g. message:{the value}). Boolean Operators Unless otherwise specified, operators are joined using the AND boolean operator, thereby restricting the search results. Parentheses can be used to force a particular precedence on complex operator expressions, otherwise OR has higher precedence than AND. Negation Any operator can be negated by prefixing it with -, for example -is:starred is the exact opposite of is:starred and will therefore return changes that are not starred by the current user. The operator NOT (in all caps) is a synonym. AND The boolean operator AND (in all caps) can be used to join two other operators together. This results in a restriction of the results, returning only changes that match both operators. OR The boolean operator OR (in all caps) can be used to find changes that match either operator. This increases the number of results that are returned, as more changes are considered. Labels Label operators can be used to match approval scores given during a code review. The specific set of supported labels depends on the server configuration, however the Code-Review label is provided out of the box. A label name is any of the following: The label name. Example: label:Code-Review. The label name followed by a ',' followed by a reviewer id or a group id. To make it clear whether a user or group is being looked for, precede the value by a user or group argument identifier ('user=' or 'group='). If an LDAP group is being referenced make sure to use 'ldap/<groupname>'. A label name must be followed by either a score with optional operator, or a label status. The easiest way to explain this is by example. First, some examples of scores with operators: label:Code-Review=2 label:Code-Review=+2 label:Code-Review+2 Matches changes where there is at least one +2 score for Code-Review. The + prefix is optional for positive score values. If the + is used, the = operator is optional. label:Code-Review=-2 label:Code-Review-2 Matches changes where there is at least one -2 score for Code-Review. Because the negative sign is required, the = operator is optional. label:Code-Review=1 Matches changes where there is at least one +1 score for Code-Review. Scores of +2 are not matched, even though they are higher. label:Code-Review>=1 Matches changes with either a +1, +2, or any higher score. Instead of a numeric vote, you can provide a label status corresponding to one of the fields in the SubmitRecord REST API entity. label:Non-Author-Code-Review=need Matches changes where the submit rules indicate that a label named Non-Author-Code-Review is needed. (See the Prolog Cookbook for how this label can be configured.) label:Code-Review=+2,aname label:Code-Review=ok,aname Matches changes with a +2 code review where the reviewer or group is aname. label:Code-Review=2,user=jsmith Matches changes with a +2 code review where the reviewer is jsmith. label:Code-Review=+2,user=owner label:Code-Review=ok,user=owner label:Code-Review=+2,owner label:Code-Review=ok,owner The special "owner" parameter corresponds to the change owner. Matches all changes that have a +2 vote from the change owner. label:Code-Review=+1,group=ldap/linux.workflow Matches changes with a +1 code review where the reviewer is in the ldap/linux.workflow group. label:Code-Review<=-1 Matches changes with either a -1, -2, or any lower score. is:open label:Code-Review+2 label:Verified+1 NOT label:Verified-1 NOT label:Code-Review-2 is:open label:Code-Review=ok label:Verified=ok Matches changes that are ready to be submitted according to one common label configuration. (For a more general check, use submittable:ok.) is:open (label:Verified-1 OR label:Code-Review-2) is:open (label:Verified=reject OR label:Code-Review=reject) Changes that are blocked from submission due to a blocking score. Magical Operators Most of these operators exist to support features of Gerrit Code Review, and are not meant to be accessed by the average end-user. However, they are recognized by the query parser, and may prove useful in limited contexts to administrators or power-users. visibleto:'USER-or-GROUP' Matches changes that are visible to 'USER' or to anyone who is a member of 'GROUP'. Here group names may be specified as either an internal group name, or if LDAP is being used, an external LDAP group name. The value may be wrapped in double quotes to include spaces or other special characters. For example, to match an LDAP group: visibleto:"CN=Developers, DC=example, DC=com". This operator may be useful to test access control rules, however a change can only be matched if both the current user and the supplied user or group can see it. This is due to the implicit 'is:visible' clause that is always added by the server. is:visible Magical internal flag to prove the current user has access to read the change. This flag is always added to any query. starredby:'USER' Matches changes that have been starred by 'USER' with the default label. The special case starredby:self applies to the caller. watchedby:'USER' Matches changes that 'USER' has configured watch filters for. The special case watchedby:self applies to the caller. draftby:'USER' Matches changes that 'USER' has left unpublished draft comments on. Since the drafts are unpublished, it is not possible to see the draft text, or even how many drafts there are. The special case of draftby:self will find changes where the caller has created a draft comment. limit:'CNT' Limit the returned results to no more than 'CNT' records. This is automatically set to the page size configured in the current user’s preferences. Including it in a web query may lead to unpredictable results with regards to pagination. Part of Gerrit Code Review Search Version v3.3.3 我要搜索这个project:SMB/EAP/PLATFORM branch:vine4-rrm,然后限制时间范围在2025年7月17好到2025年9月9号之间的 我应该输入什么搜索关键字
最新发布
12-04
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值